AI Use and Transparency Statement

1. About this statement

1.1 Why this statement exists

Artificial intelligence is now part of how the Classe365 and Hiree365 platforms work. Institutions, regulators, parents and students are entitled to know exactly what that means: which features use AI, what data those features see, what we do and do not do with that data, who is accountable for the decisions that follow, and where the limits are.

This statement answers those questions in one place. It is written to be read by a school administrator, a data protection officer, a procurement team, a parent or a student — not only by a lawyer. Where a commitment is limited, we say so plainly rather than implying more.

1.2 Which platforms it covers

• Classe365 — our student information system, learning management system and CRM for education institutions.
• Hiree365 — our campus recruitment and employability platform, used by students seeking employment, institutions running campus placement programmes, and employers seeking candidates.

Both platforms are operated by the same group. This statement covers both unless a section says otherwise.

1.3 Which entity is responsible

Customers located in the United States contract with 365 Software, LLC, a Delaware limited liability company, registered office 131 Continental Dr, Suite 305, Newark, DE 19713, New Castle County, United States.

Customers located anywhere else — including the European Union, the United Kingdom, Australia and the rest of the world — contract with Sprout On Web Pty Ltd, ABN 72 138 602 418, registered office 22 Palm Street, St Ives, NSW 2075, Australia.

Support and engineering services are provided by Classe365 India Pvt Ltd, 37, Venjay Edifice Complex, 3rd Floor, JLB Road, Chamarajapuram, Mysuru – 570 005, India.

Together we are “Classe365”, “we”, “us” and “our”.

1.4 Roles: who is the deployer, who is the provider

The distinction matters, particularly under European law.

• We are the provider of the AI features built into the platform. We design them, we decide how they are built, and we are responsible for the obligations that fall on a provider.
• The institution is the deployer. It decides whether to switch a feature on, who may use it, what it is used for, and what weight is given to its output. It also decides what data exists in its tenant for a feature to analyse.

Under data protection law the same split applies: the institution is the controller of student, learner and candidate data, and we process that data on its instructions.

1.5 Related documents

Read this statement together with our Privacy Policy, our Children’s Privacy Policy, our US State Privacy Notice, our Data Retention Schedule, our Sub-processor List and our Security Statement. Where a term is defined in the Privacy Policy, it has the same meaning here. Where international transfers are relevant, our Personal Data Processing Agreement and our International Data Transfers page govern, and we do not restate their terms in this statement.

2. Our core commitment: your data does not train anyone else’s model

2.1 The commitment

We do not use customer, student or candidate data to train, fine-tune or improve any general-purpose or shared AI model.

This is the single most important thing in this statement, and it is not qualified elsewhere in this document.

2.2 What that means in practice

Where a feature uses a model that learns from data:

• that model is trained only on that customer’s own data — it is a per-tenant model;
• it is used only for that customer;
• data is never pooled across customers; and
• one institution’s data is never used to improve the service for another institution.

A pattern learned from one school’s records stays inside that school’s tenant. It does not become part of a model that another school, another university, another training provider or another employer benefits from. There is no shared learning layer sitting across our customer base, and we do not build one.

2.3 What we do not do with your data

To remove any doubt, we do not:

• contribute customer, student or candidate data to the training corpus of any general-purpose or foundation model;
• use education records, learner records or candidate records to train models that serve other customers;
• use student, learner or candidate data for advertising, advertising profiles or targeted advertising;
• sell student, learner or candidate data; or
• use AI features to make decisions about students or candidates on the institution’s behalf without a person in the loop (see section 7).

2.4 Why we take this position

Education data is among the most sensitive data any organisation holds. It follows a person for years, it is often about a child, and the institution that collected it holds it in trust. Pooling it to improve a shared model would break that trust, however carefully the pooling was engineered. We have chosen the architecture that makes the promise easy to keep rather than the one that makes it hard to verify.

3. The AI features in the platform

3.1 The full list

The table below lists every AI feature in Classe365 and Hiree365, what it does, and the data it uses. In every case the data used is data that already exists inside that institution’s own tenant, placed there by the institution or by its users in the ordinary course of using the platform.

3.2 What is not on this list

If a capability is not in the table above, it is not an AI feature of the platform. In particular:

• We do not perform facial recognition or voice recognition. Classe365 and Hiree365 do not themselves collect, store or process biometric identifiers — including fingerprints, handprints, retina or iris patterns, genetic data, voiceprints, gait patterns, facial templates or faceprints. An institution may choose to enable SMOWL, a third-party online quiz proctoring service, which it contracts with directly under SMOWL’s own terms. Any biometric processing by SMOWL occurs under SMOWL’s own terms and privacy policy, not ours.
• We do not collect audio recordings of children’s voices.
• We do not use AI to profile students for advertising, and we do not build advertising profiles of students, learners, candidates or children.

3.3 Where AI features sit

AI features operate inside the authenticated platform, against the institution’s own tenant. They do not operate on our public marketing website, and the analytics and marketing technologies that run on that website do not feed any AI feature. Our Cookie Policy explains that separation in detail.

4. Transparency: you are told when you are dealing with an AI

4.1 Article 50 of the EU AI Act

Article 50 of the EU Artificial Intelligence Act requires that people are told when they are interacting with an AI system, unless that is obvious to a reasonably well-informed person. These transparency obligations have applied since 2 August 2026.

We meet that obligation, and we apply it to every user of the platform — not only to users in the European Union. A student in Sydney, Singapore or São Paulo is told the same thing a student in Dublin is told.

4.2 The AI chat assistant

The AI chat assistant is an AI system, and users are told so. Where the assistant is enabled in a tenant:

• it is labelled as an AI assistant in the interface, at the point where a user starts or continues a conversation with it;
• its responses are presented as AI-generated responses, not as messages from a member of staff or from our support team; and
• a user is never led to believe that they are speaking to a human being when they are speaking to the assistant.

The assistant is also not a substitute for our support team. Where a user needs a person, our support channels remain open at clientservice@classe365.com.

4.3 The other features

The remaining features in section 3.1 produce analysis, suggestions or drafts inside administrative and teaching screens rather than conversation. Where a screen presents an AI-generated score, ranking, risk indicator, suggestion or draft, it is identified as AI-generated in that screen, so that the member of staff reading it knows what they are reading before they act on it.

For the writing assistant, the person using it knows they are using it — they invoke it deliberately. Institutions remain responsible for their own academic integrity rules about when students may use drafting assistance and how its use must be declared.

4.4 Institutions must not remove the labelling

Institutions configure a great deal about the platform. They may not configure away the AI labelling described in this section, and our Acceptable Use Policy treats an attempt to present an AI feature as a human being as a misuse of the service.

5. High-risk AI systems: our position and our timetable

5.1 What Annex III says

Annex III of the EU AI Act classifies certain AI systems as high-risk, including systems used in education and vocational training and systems used in employment, worker management and access to self-employment, which includes recruitment. High-risk systems carry substantial obligations: risk management, data governance, technical documentation, logging, accuracy and robustness requirements, human oversight design, conformity assessment and registration.

Following the Digital Omnibus, the Annex III high-risk obligations apply from 2 December 2027.

5.2 Which of our features fall in scope

We have assessed our features against Annex III, and we state the result plainly rather than arguing our way out of it. The following fall within the scope of the education and employment/recruitment high-risk categories:

• Attrition tracking — it identifies students at risk of disengaging or withdrawing, which bears on a student’s access to and progress through education.
• Behaviour analytics — it analyses engagement and behavioural patterns of students.
• Grading analysis — it analyses assessment results and grading patterns, which bears on the evaluation of learning outcomes.
• Hiree365 candidate processes — the parts of Hiree365 that support recruitment and the placement of candidates with employers.

5.3 What we commit to, and what we do not claim

We commit to compliance with the applicable high-risk obligations for these features by 2 December 2027.

We do not claim conformity today. As at the effective date of this statement, we have not completed a conformity assessment for any high-risk AI system, we do not hold a CE marking for any AI system, and no statement in this document should be read as a declaration of conformity. Any institution told otherwise by anyone has been told something we do not say.

5.4 What we are doing between now and then

Our programme to reach that date includes: completing and maintaining technical documentation for each feature in scope; formalising the risk management process that already sits behind feature design; documenting data governance for the per-tenant training described in section 2; extending logging so that the operation of a feature can be traced and reviewed; formalising the human oversight design that section 7 describes; and preparing the instructions for use that a deployer needs in order to meet its own obligations.

Institutions deploying a high-risk system have their own obligations under the Act — including human oversight, input data relevance, monitoring and, in some cases, informing affected people and carrying out a fundamental rights impact assessment. We will provide the information a deployer reasonably needs from us to meet those obligations. We cannot meet them on the institution’s behalf.

5.5 If an obligation arrives sooner

If a feature we operate becomes subject to an obligation earlier than the date stated above — because the law changes, because a regulator issues guidance, or because we extend a feature into new territory — we will meet the earlier date and we will update this statement to say so.

6. General-purpose AI models

Some features are built on general-purpose AI models. Where that is the case:

• the model is used to process the institution’s data in order to produce a result for that institution;
• the institution’s data is not used to train, fine-tune or improve that model, consistent with section 2;
• the arrangement is covered by our contractual terms with the provider concerned; and
• the processing is subject to the same security controls, access controls and retention limits that apply to the rest of the platform, as set out in our Security Statement and Data Retention Schedule.

We do not develop general-purpose AI models ourselves, and we do not place a general-purpose AI model on the market.

7. Human oversight: the institution decides

7.1 All AI output is advisory

Every output of every AI feature listed in section 3.1 is advisory. It is information presented to a person so that the person can make a better decision. It is not a decision.

An attrition risk indicator is a prompt to look at a student’s situation, not a finding that the student will withdraw. A grading analysis is an observation about a pattern in marks, not a mark. A plagiarism check reports a likelihood, not a finding of misconduct. A candidate ranking in Hiree365 is a suggested order of review, not a hiring decision or a rejection.

7.2 Decisions about students remain with the institution

Decisions about students, learners and candidates remain with the institution and its staff. That includes decisions about admission, enrolment, progression, assessment, grading, discipline, academic integrity, support and intervention, placement, and referral to an employer.

We do not make those decisions. We do not have the authority to make them, we do not exercise judgement on the institution’s behalf, and no configuration of the platform transfers that judgement to us.

7.3 No significant automated decisions without human review

No AI feature in the platform produces a legal effect or a similarly significant effect on a person by automated means without human review. Where the output of a feature would feed into such a decision, a member of the institution’s staff must review the output and take the decision.

That reviewer must have the authority to disagree with the output, the information needed to disagree with it, and a route to reach a different result. A review that only ever confirms what the system suggested is not the oversight this section describes, and institutions should design their processes accordingly.

7.4 What we build to support oversight

Human oversight has to be designed in, not asserted. In support of it we: label AI-generated output where it is presented; keep AI output separate from the institution’s authoritative records, so that a suggestion is never mistaken for a fact on file; give institutions the ability to switch features off (section 9); and restrict which roles can see which analytics, so that sensitive indicators are not broadcast across an institution.

7.5 Rights of students, parents and candidates

Where an individual has the right to obtain human intervention in a decision, to express a point of view, or to contest a decision, that right is exercised with the institution, because the institution is the controller and the decision-maker. Our Privacy Policy explains how we support institutions in responding to those requests. Under FERPA, parents and eligible students exercise inspection, correction and hearing rights through the institution, and we support the institution in fulfilling them.

8. Accuracy, limitations and the possibility of error

8.1 AI features can be wrong

AI features can produce output that is incomplete, outdated, misleading or simply wrong. This is a property of the technology, not a defect we expect to eliminate, and no amount of engineering removes it entirely. We say so here because a statement that implied otherwise would be worse than useless to the people relying on it.

8.2 The specific limitations institutions should plan around

• The chat assistant may state something incorrectly. It answers from platform content and records; it can misread a question, miss context, or express something with more confidence than the underlying information supports. Important answers should be verified against the record itself.
• Analytical features find patterns, not causes. Attendance analysis, grading analysis, behaviour analytics and attrition tracking identify correlations in the data an institution holds. They cannot see why a pattern exists — illness, caring responsibilities, a change at home, a data entry error or a timetable clash all look similar in the data.
• Risk indicators produce false positives and false negatives. Attrition tracking will flag students who were never going to leave, and it will fail to flag students who do. It is a way of directing attention, not a prediction to be relied on.
• Plagiarism checking reports likelihood, not misconduct. A high similarity score can reflect quoted material, common phrasing, a shared template or a properly cited source. A low score does not prove originality. An academic integrity finding must rest on a human assessment of the work.
• Output quality depends on the institution’s own data. Records that are incomplete, inconsistent, out of date or entered differently across departments will produce analysis with the same faults. Features do not correct the underlying data.
• New and unusual situations are handled worst. A pattern that has not appeared in a tenant’s history is the pattern a model trained on that tenant’s history is least equipped to recognise.
• The writing assistant drafts; it does not verify. Text it produces must be read, corrected and owned by the person who sends it.

8.3 What we do about accuracy

We test features before release and monitor them afterwards. We investigate reports of incorrect output. Where a feature is found to be materially unreliable for a purpose, we will correct it, restrict it, or withdraw it — and we would rather withdraw a feature than leave an unreliable one running against student records.

8.4 What institutions should do about accuracy

Treat AI output as one input among several. Verify anything that matters against the underlying record. Do not adopt a workflow in which an AI output moves straight into a consequence for a student without a person looking at it. Tell staff what the features can and cannot do — this statement is written so that it can be shared with them directly.

8.5 Reporting a problem

If an AI feature produces output that appears wrong, unfair or harmful, tell us at clientservice@classe365.com. Describe what the feature produced and what you expected. We investigate reports of this kind, and we would rather receive one that turns out to be nothing than miss one that was not.

9. Turning AI features off

9.1 Institutions control what is enabled

AI features are configurable by the institution. An institution may:

• disable AI features across its tenant, so that no user of that institution has access to any of them;
• disable individual features, keeping those it wants and removing those it does not;
• restrict features by role, so that, for example, only designated staff can see attrition indicators or behaviour analytics;
• restrict features by user group, including switching features off for particular cohorts, year groups or age groups; and
• decline to enable a feature at any point, including at initial configuration, so that it is never switched on in the first place.

9.2 How to switch a feature off

An institution’s administrator can configure AI feature settings from the platform’s administration area. If the setting you need is not where you expect it, or you want the entire set disabled at tenant level, write to clientservice@classe365.com and we will action it.

9.3 What happens when a feature is disabled

Disabling a feature stops it operating for the users it has been disabled for. The rest of the platform continues to work. The institution’s underlying records are not deleted by disabling a feature, because those records are the institution’s records, held under our Data Retention Schedule — they exist independently of whether a feature analyses them.

9.4 Individual users

A student, parent or member of staff who does not want an AI feature applied to them should raise it with their institution, because the institution decides what is enabled and for whom. Institutions can restrict features by user group as described above. Where an institution asks us to help configure such a restriction, we will.

10. Bias and fairness

10.1 Why this needs saying

Systems that analyse patterns in historical records can reproduce the patterns in those records, including patterns that reflect disadvantage rather than ability. In education this matters more than almost anywhere: an indicator that quietly tracks a student’s background rather than their engagement can shape how that student is treated for years.

10.2 What our architecture does and does not do about it

Our per-tenant approach (section 2) has a direct consequence for bias, in both directions, and institutions should understand both:

• It contains the problem. A bias present in one institution’s records cannot travel into another institution’s model, because there is no shared model. No institution inherits a distortion from a customer base it has never met.
• It does not remove the problem. A model trained only on one institution’s data will reflect that institution’s data — including any historical inequity in it. Confining a bias is not correcting it.

We would rather say this than let the per-tenant design be read as a claim of fairness it does not support.

10.3 What we do

• We design analytical features to surface indicators for human attention rather than to allocate outcomes automatically, which keeps a person between the pattern and the consequence.
• We keep AI output separate from authoritative records, so that a contested indicator does not become part of a student’s permanent file by default.
• We provide role-based restrictions so that sensitive indicators reach only the staff who need them.
• We investigate reports of biased or unfair output, and treat them as product defects.
• Fairness and non-discrimination form part of the data governance and risk management work described in section 5.4, ahead of the December 2027 date.

10.4 What institutions should do

• Decide, before enabling a feature, what will happen when it flags a student — a supportive conversation is a very different consequence from an administrative one.
• Look at who is being flagged. If indicators cluster around a particular group, treat that as a signal about the data or the process, not as a finding about the students.
• Never use an AI indicator as the sole basis for a decision that affects a student’s access, progression or standing.
• Tell staff that the output is advisory, and mean it — give them the standing to disagree with it.

10.5 Hiree365 and candidates

In Hiree365, ranking or shortlisting suggestions are advisory and are reviewed by the institution and the employer. Employers receive student personal data only via the institution. We do not disclose candidate data directly to employers; the institution controls what is shared as part of its placement programme. No candidate is rejected, excluded or deprioritised by automated means without human review.

11. AI and children’s data

11.1 Our position

Where an institution uses the platform with children, the same commitments apply, and several additional ones.

• Children’s data is not used to train, fine-tune or improve any general-purpose or shared AI model. Section 2 applies to children’s data without exception.
• We do not use AI to profile children for advertising. We do not permit targeted advertising to children, we do not build advertising profiles of children, and we do not sell children’s data.
• We do not collect audio recordings of children’s voices, and no AI feature processes such recordings.
• We do not perform facial or voice recognition on children, consistent with section 3.2. Where an institution enables SMOWL, any biometric processing occurs under SMOWL’s own terms and privacy policy, and the institution contracts with SMOWL directly.

11.2 Institutional control and parental consent

The institution decides whether AI features operate for children in its tenant, and can disable them entirely or by year group under section 9. Where parental consent is required for the processing of a child’s personal information, the institution obtains it, and our Children’s Privacy Policy explains how consent, separate consent for optional disclosures, and parental rights work. Personal information collected from children is retained under our Data Retention Schedule and deleted on the timelines published there.

11.3 Hiree365

Hiree365 has a minimum age of 16. It is not available to anyone under 16, and there are no under-13 users. The AI features that support candidate processes therefore do not operate on the data of children under 16 in Hiree365.

11.4 Age-appropriate use

AI features were designed for use inside an institution’s own environment, under the supervision of that institution’s staff, and with the safeguards described in this statement. We encourage institutions using the platform with younger learners to consider carefully which features are appropriate for which age group, and to use the role and group restrictions in section 9 rather than enabling everything by default.

12. Security, retention and access

AI features are part of the platform, and they inherit the platform’s protections rather than sitting outside them.

• Security. The controls described in our Security Statement apply — AWS infrastructure, TLS in transit, encryption at rest, network segregation, least-privilege access control, an OWASP-aligned secure development lifecycle, daily backups, DDoS protection and monitoring. Our SOC 2 Type II audit is in progress with expected completion in December 2026; we do not claim certification, and we do not hold an ISO 27001 certification.
• Retention. Data processed by AI features is held under our Data Retention Schedule and deleted on the timelines published there. A record deleted by the institution is permanently deleted after 7 days; all customer data is permanently deleted within 30 days of subscription termination.
• Access. Personnel of Classe365 India Pvt Ltd in Mysuru, India provide support and engineering services and may access customer data, including student data, for those purposes. That access is subject to access controls, contractual confidentiality obligations and intra-group data transfer agreements. It is disclosed here for the same reason it is disclosed in our Privacy Policy and Security Statement: because institutions are entitled to know who can see their data.
• Sub-processors. Our Sub-processor List identifies every sub-processor that receives student or candidate data, and separately identifies the providers that operate on the marketing website only and never receive student or candidate records.
• International transfers. Where personal data is transferred across borders, the mechanisms set out in our Personal Data Processing Agreement and described on our International Data Transfers page govern.

13. Governance and accountability

13.1 Before a feature is released

New AI features and material changes to existing ones are reviewed before release against the commitments in this statement: whether the feature can be built without pooling data across customers; what data it needs and whether that is the minimum; whether its output is advisory and how the interface makes that clear; how it should be labelled; whether it falls within an Annex III category; who should be able to see its output; and how it can be disabled.

13.2 After release

We monitor features in operation, investigate reports of incorrect, unfair or harmful output, and maintain the documentation described in section 5.4.

13.3 Our commitments do not change with the technology

The models behind a feature may change. The commitments in section 2 do not. If we ever needed to change them, we would give notice under section 14 and institutions would be free to act on that notice — including by disabling the features concerned or by exercising their cancellation rights.

14. Changes to this statement

We review this statement at least annually, and whenever we add, remove or materially change an AI feature, or when the law that governs one changes.

Where a change materially affects how AI features process customer, student or candidate data, we will give at least 30 days’ notice before it takes effect, by a notice on classe365.com and by email to institutional account contacts. Minor corrections — a clarified sentence, a renamed feature, a fixed link — take effect when published.

Each version carries a “Last updated” date and an “Effective” date at the top. The current version is dated 15 September 2026 and takes effect on 15 October 2026.

15. Contact us

Questions about this statement, about an AI feature, or to report incorrect or unfair AI output: clientservice@classe365.com Support: clientservice@classe365.com Accessibility line: +61 2 9472 5000

By post — United States customers: 365 Software, LLC 131 Continental Dr, Suite 305 Newark, DE 19713 United States

By post — all other customers: Sprout On Web Pty Ltd 22 Palm Street St Ives, NSW 2075 Australia

If you are a parent, a student, a candidate or a school administrator and you want to know exactly which AI features are switched on in your institution’s tenant, ask your institution — it holds that configuration. If your institution needs help answering, write to us and we will tell it.

Classe365 and Hiree365 are operated by 365 Software, LLC (United States customers) and Sprout On Web Pty Ltd (all other customers), with support and engineering services provided by Classe365 India Pvt Ltd.