Where data is stored matter but also how it is structured.
When a faculty member uploads a student's essay to an AI grading tool, they aren't just sharing text. Under FERPA, that essay is an official education record — protected by federal law. So the question of how a vendor stores that record is a legal and ethical responsibility.
Every vendor you meet is going to say: “we are FERPA compliant, we store all our data in the US, and none of it will leave the US.” Nice, but, have they really thought about privacy, security, and data as core parts of their business or just check marks?
One differentiator is how vendors store their data.
Think of an apartment building. Dozens of tenants share one building with the same hallways, the same plumbing, the same front door. Every unit has its own lock but a break-in at the front door puts everyone at risk. The landlord saves money by housing everyone together.
Now picture a street of single-family homes, image every family gets their own house (IKR? in this economy?!). But let’s just imagine it: a break-in at one house stays at that house because no one is sharing any doors.
TLDR: Giving everyone their own house is a lot more work to set up and maintain!
That's the difference between multi-tenant and single-tenant data architecture.
Many SaaS tools, including AI tools used in higher education, use multi-tenant architectures. Some use shared databases, while others separate customers through schemas, shards, or other controls. It's less trouble to set up and maintain at scale, but institutions should understand exactly how their student data is isolated.
TimelyGrader is the single-family home. Every institution gets its own dedicated space, its own separate database, and a contractual guarantee that one university’s data will not be shared with another university’s data.
What "Multi-Tenancy" Actually Means
Multi-tenancy is a design where one copy of an application serves many customers at once. From a business point of view, it makes sense — one system, one setup, shared costs. The vendor saves a lot through scale.
From a data-protection point of view, it's more complicated.
The shared-database problem
Back to the apartment building. In one common multi-tenant design, your students' records live in the same database as records from other institutions on the platform — like every tenant's valuables kept in one building safe, separated by labeled compartments. What keeps University A from seeing University B's data is software: filters and access rules that are supposed to catch every request. Other multi-tenant designs may add schemas, shards, or other isolation layers.
The risk isn't hypothetical. Security experts at OWASP note that it takes just one overlooked rule for one tenant to read, change, or delete another tenant's data. Put plainly: a single coding mistake in a shared database can expose every institution's student records at once.
And these mistakes happen. IBM's 2023 Cost of a Data Breach Report found that 82% of breaches involved data stored in the cloud, with misconfigurations among the top causes. In a shared system, one tenant-isolation or configuration failure can potentially affect multiple institutions on the platform.
The "blast radius" problem
In security, blast radius is just a way of asking: when something goes wrong, how many people get hurt? Shared infrastructure can make that number much bigger.
Remember the 2023 MOVEit breach? A single flaw in widely used file-transfer software exposed personal information across more than 2,500 organizations. The attack didn't depend on one institution making a mistake — a common vulnerability affected organizations at scale.
For colleges and universities, FERPA raises the stakes even higher. Student records aren't just sensitive — they carry specific federal protections. A breach that exposes grades and submissions from many institutions at once isn't only an IT problem. It can also create serious FERPA compliance and notification concerns.
FERPA and the AI Grading Question
FERPA doesn't ban AI tools that handle student records. It sets conditions. To receive student data without asking each student for consent, a vendor has to qualify as a "school official" — which means meeting four requirements:
The limits on re-using and re-sharing data are where the "do you train on our data?" question becomes essential.
The AI-training risk
Many AI platforms get better over time by learning from what users feed them. In grading, that would mean student essays, submissions, and instructor feedback could end up training the vendor's AI — not just for your institution, but as part of a shared pool that benefits every other school on the platform.
EdTech Magazine's 2026 analysis called this the most overlooked risk in AI buying: student data should never quietly improve a vendor's external model, and it should be kept for the shortest time possible.
TimelyGrader does not train its AI on student data — not yours, not anyone's. The AI is pre-trained on general academic content and works against your rubrics. Student work comes in, feedback goes out, and none of it is used to improve anyone else's model. That protection comes from TimelyGrader's data-use policy, contractual controls, and architecture; single-tenancy adds an additional layer of institutional data isolation.
What to Ask Before You Sign
Legal guidance for higher ed recommends getting clear, written answers to three questions before deploying any AI tool that touches student records:
These are baseline questions for evaluating a vendor's FERPA posture and data-governance practices. Any vendor that can't answer all three clearly and in writing shouldn't be handling your students' records.
Single- vs. Multi-Tenant, Side by Side
The LMS Precedent
This isn't a new debate. Major LMS platforms have long treated tenant isolation as a core security requirement for sensitive student records, whether that isolation is implemented through dedicated or multi-tenant architectures. The reasoning is the same: student data is too important to rely on vague assurances about separation.
AI grading tools handle the very same kinds of data — submissions, grades, feedback, performance records. The standard for isolation should be just as high. If an AI grading platform uses shared infrastructure, it's worth asking exactly how institutional data is separated, tested, and audited.
How TimelyGrader Works in Practice
When an institution deploys TimelyGrader, it gets its own environment — its own application, its own database, its own storage. No other institution's data lives there, and no other institution's users can reach it.
Here's what that means day to day:
Your institutional data stays isolated. When a student submits an assignment, it flows from your LMS into your TimelyGrader instance. The AI reviews it against your rubric, drafts feedback, and hands it back to your faculty. No other TimelyGrader institution's data is stored in your database. Where authorized subprocessors are used to provide the service, data is transmitted under applicable contractual and security controls and is not used to train shared AI models. There's no shared TimelyGrader database to accidentally query across institutions.
Faculty stay in control. TimelyGrader treats AI output as a draft, never a final grade. Faculty review, edit, and approve every piece of feedback before it reaches a student. That human-in-the-loop workflow supports your institution's FERPA direct-control obligations alongside the contractual and operational controls governing use of education records.
Leaving is clean. In shared systems, offboarding can require deletion to be verified across systems where your records may be stored alongside others. With a single-tenant setup, dedicated data stores simplify deletion and verification. We can shut down your instance and delete institutional data according to the applicable retention and deletion terms, including with relevant subprocessors where applicable.
The Questions Every Institution Should Ask
Architecture rarely shows up in marketing materials — multi-tenant vendors seldom advertise that your records share space with other universities. So ask directly:
These aren't adversarial questions. A vendor with a well-built architecture will answer them confidently. One that hedges or changes the subject is telling you something.
Architecture Is a Values Statement
Multi-tenancy isn't irresponsible everywhere — for plenty of software, it's the right call. But higher education handles a specific kind of data, protected by a specific federal law, generated by students who have no say in which tools their school buys. That context changes the math.
A shared-database multi-tenant vendor is making a trade: operational efficiency in exchange for relying more heavily on logical tenant-isolation controls. For a project tracker or a survey tool, that may be reasonable. For a platform handling student academic records, that trade deserves closer scrutiny.
Single-tenant architecture costs more to build and more to run. TimelyGrader chose it on purpose — because the institutions we serve need strong isolation for student records. When your student data is in our system, it belongs to your institution, remains isolated from other TimelyGrader institutions, and is never used to make anyone else's AI smarter.
That's not a feature. It's the standard we think every AI tool that touches education records should meet.
Evaluating AI grading tools and want to see how TimelyGrader's architecture supports your FERPA obligations? Request a conversation with our team — we'll walk through the architecture, answer the hard questions, and give your IT and legal teams the documentation they need.
