A psychoeducational evaluation is one of the most sensitive documents a clinician produces. It holds a parent's account of what home has been like. It holds medical history, sometimes a diagnosis, sometimes a prescription. It holds test scores that will follow a child for years, and a professional's judgment about what those scores mean. An IEP, a 504 plan, a progress letter, or a handout written for a family carries the same weight in fewer pages.
Districts and practices have good reasons to be careful about where that information goes. Breaches make the news, and every clinical director has heard of practitioners pasting a case into a consumer chatbot because it was faster than the alternative.
Hesitation around AI and student data is completely justified. You deserve straight answers on who holds your data, how the AI uses it, who can view it, and how risks are mitigated. We wrote this guide for every stakeholder on the hook for compliance: from the IT directors and district leaders signing off on the platform to the SLPs, PTs, OTs, and psychologists using it daily.
Which law covers the record
The first question a reviewer asks is which law applies, and the honest answer is that it depends on who is writing the document.
When a district-employed or district-contracted clinician writes an evaluation, an IEP, a 504 plan, or a letter to a family, that document is an education record under FERPA and IDEA. HIPAA does not govern it, even when the district bills Medicaid for related services. The Department of Education and the Department of Health and Human Services published joint guidance on exactly this point. In that setting, SageReport operates as a "school official" under FERPA. In plain terms: we perform a function the district would otherwise use its own staff for, we act under the district's direct control, we use the information only for that purpose, and we do not disclose it to anyone else. Those obligations are written into the data privacy agreement we sign with each district, along with the state requirements that apply to it, such as New York's Education Law 2-d, Illinois' SOPPA, Louisiana's student data privacy law, and California's student privacy statutes.
When a clinician in private practice uses SageReport and bills insurance, the picture changes. That clinician is a HIPAA covered entity, and SageReport is their business associate. For those accounts we sign a Business Associate Agreement, and the HIPAA Privacy and Security Rules govern how we handle their records.
We built the platform to meet both frameworks, because both kinds of clinicians use it, and many practitioners move between the two over a career. The point of explaining the difference is that it tells you which document to read. If you are a district, the DPA is the one that binds us. If you run a practice, it is the BAA.
Where the data goes
Here is the path a student's information takes in SageReport, from the moment a clinician uploads a file to the moment a document is finalized.
It lands on Google Cloud, in the United States. Uploaded documents, extracted text, drafts, and finished documents are stored in Google Cloud data centers in the US. Everything is encrypted in transit with TLS 1.2 or higher and at rest with AES-256. The application is serverless, which means there are no virtual machines of our own to patch and no VPN into a data center.
AI processing happens inside the same environment. All of SageReport's AI runs through Google Cloud's Gemini Enterprise Agent Platform, formerly known as Vertex AI, using Gemini and Claude models served by Google. Student information never goes to a consumer chat product, and it never goes to an AI provider's public API. The Business Associate Agreement we hold with Google covers the AI platform along with storage and everything else we use. Under that arrangement, Google does not retain prompts or outputs after the request completes and does not use them to train any model. Neither do we. Student information is used to write that student's documents, and nothing else.
Any AI provider we add in the future has to meet the same bar before a single student record touches it: a SOC 2 Type II report, a signed BAA, zero data retention, and processing in the United States.
The finished document comes back to the clinician. Exports are generated in memory and returned to the clinician's browser. We do not keep a copy of the exported file on our servers.
Beyond Google Cloud, a small number of services support the platform. They are designed to receive only account data about the practitioner, such as a user ID or email address, and our error and analytics tools are configured to mask content. We list every one of them for districts and give 30 days' notice before adding a new one that would handle any customer data.
Who can see it
Inside a district or a practice, the boundary is the organization. Every organization's data lives in its own partition, and the access rules are enforced at the database layer, not just in the interface. A clinician sees their own documents and the ones a colleague has shared with them. An administrator can see across the team when clinically appropriate. Sharing an evaluation with a colleague creates a permanent audit record of who had access and when, and revoking access takes effect immediately.
Inside SageReport, very few people can reach production data at all. Day-to-day development happens in separate environments with synthetic data. Production access is limited to a small number of senior engineers, and nobody else at the company has credentials that reach student records. The internal tools our support team uses show account metadata and never display student names, document content, or uploaded files. When an engineer does need to look at production data to fix a problem, the access is logged by Google Cloud's audit logging, and those logs are retained for seven years. A district or practice can ask us for an accounting of who accessed its records and we will provide it.
Everyone who works at SageReport passes a background check before they can touch anything, signs a confidentiality agreement, and completes security, HIPAA, and FERPA training every year. Access is removed within a day of someone leaving.
For districts that use single sign-on, SageReport authenticates through the district's own identity provider using SAML, which means the district's password and multi-factor policies apply automatically. Administrators can also set an inactivity timeout for their whole team.
The clinician is the author
SageReport drafts. The clinician decides. There is no path in the platform where a document is finalized without a practitioner reviewing it, and the platform makes no eligibility, placement, diagnostic, or service decision on its own. Every sentence that ends up in front of a parent, an IEP team, or a client was accepted by a licensed professional who is responsible for it.
We are direct about this because it is where the real remaining risk lives. We use the most capable models available and move to better ones as they arrive, and we evaluate what they draft carefully. We do not compete on cost; we compete on quality and security, because bad AI output is a risk to students and to districts. Even so, any AI can produce a confident sentence that is wrong: a misread score, an overstatement, a recommendation that does not follow from the data. No amount of infrastructure fixes that. Professional review does. Because SageReport's drafts are so solid, we train all users to approach every statement with scrutiny and skepticism and we are proud that the average time writing a report inside SageReport is 1.9 hours. There is a reason our users report that, even after saving 75% of their writing time, their reports more accurately reflect what they mean to say about their students. They report that the time allows them to think more deeply about their findings and what they want to communicate. This is the model for responsible AI use. Use the capacity created to do better clinical work, not offload it, and that is what we see day in and day out from our focus groups and usage data. If you want a graduate educator's view on what that review requires, Jeffrey Kirsh wrote about it on this blog in "AI Won't Replace Your Critical Thinking: It will expose whether you have any."
Keeping it, and letting it go
A district's records belong to the district, and a practice's records belong to the practice. We hold them for as long as you are using the platform, and then we let them go on a schedule you can plan around. If we ever have a security incident affecting your data, our district agreements commit us to notify the district within 72 hours of confirming it, with what we know and what we are doing, and our Business Associate Agreement commits us to notify practices as well. We have not had an incident requiring notification, and we intend to keep it that way, but we would rather you know the commitment now than learn it during a bad week.
What we have had checked
We are a young company, and we knew from the start that districts and practices would need more than our word. So we did the work that established vendors are expected to have done, early, rather than waiting to be asked.
An independent CPA firm, CertPro, audited our security, availability, and confidentiality controls under the AICPA's SOC 2 framework. The report is available to IT and compliance teams under NDA through our Trust Center at trust.sagereport.com, alongside our policies, DPA, and other procurement documents.
We commissioned an independent penetration test of the application, which found no critical, high, or medium-severity issues. We tested restoring our data from backup end to end and timed it, so our recovery estimates rest on a measured run rather than an assumption. We ran a full incident response exercise with the leadership team, found the kind of gaps only a live exercise finds, and addressed them. We review every vendor we depend on annually. All of this gives the people evaluating us something to verify instead of something to believe.
Questions worth asking any vendor
If you are evaluating an AI platform for clinical documentation, in a district or in a practice, these are the questions we think matter most. They are drawn from state guidance and the national student data privacy agreements districts already use. Our answers are above; ask every vendor for theirs, in writing.
- Which law governs the records in your product, and which agreement will you sign with us?
- Where is the data stored, and is it encrypted in transit and at rest with named standards?
- Which AI models process student or client information, through which provider, and under what data retention and training terms? Is a BAA in place with that provider?
- What limits what the model sees?
- Who at your company can access our records, how is that access logged, and can we get an accounting of it?
- What are your retention and deletion timelines, and do you certify deletion at contract end?
- Can the platform finalize any document without a licensed professional reviewing it?
- What is your incident notification commitment, in hours?
- What independent verification can you share, and can our IT team read the actual report?
If you would like to walk through any of this with your IT or compliance team, we will get on the call. Security reviews are part of the job, and we would rather answer the hard questions before a contract than after one.