AI for K-12 software
AI for your K-12 product, built on synthetic data, not student records.
For K-12 SaaS vendors. We work for you as your subprocessor, not for the district: staff-, teacher- and parent-facing AI inside your product, built on synthetic data and shipped under your name, while production student data stays in your US cloud under your controls.
Built for: K-12 SaaS vendors serving districts, schools, teachers and families.
How we handle student data
These are design facts about how we work, not compliance claims. Your counsel decides how your agreements apply.
- We work for you, the vendor, and sign the data terms your district agreements require of anyone working on your product.
- We build and test on synthetic or de-identified data. Production student data stays in your US cloud, under your access controls. In production we work only through access you grant, and you can revoke it at any time.
- We don't use children's data to train models, and features for users under 13 are designed with COPPA's parental-consent requirements in mind.
- We work within your FERPA, COPPA, accessibility and institutional requirements, with an approval gate before anything is written and an audit log with deletion.
Where these products get stuck
What gets in the way, and how we handle it.
- 01
Districts write the rules
Built around your district agreements
Synthetic data in Sprints, production data in your US cloud, and we sign the data terms your district agreements require.
- 02
Teachers and parents need answers
Teacher and parent help from your help center
Docently answers term-start questions with the article linked, and hands the rest to support.
- 03
Admins want answers, not report requests
Admins ask the data directly
Cohortly answers in plain English, within each district's permissions.
- 04
Registration paperwork piles up
Registration documents pre-filled for staff to check
Pathly reads scans into the record with a source for each field; office staff approve.
AI inside your product
The modules and services that fit this kind of platform.
Each one is shown on a fictional institution.
What it connects to: Synthetic data only in the Build Sprint. Rostering and SIS data stay in your cloud; modules read through your product's existing permissions and APIs.
A support agent for your learners and admins, grounded in your help center.
Fits: LMS support, student services
From the first program question to a checked application.
Fits: Admissions, enrollment, credentialing, CE and corporate learning catalogs
Ask your enrollment and retention data a question in plain English.
Fits: SIS, analytics, student success, compliance-training completion
An AI-assisted review of your product against WCAG 2.1 AA, with fixes your team can ship.
Fits: Any vendor selling to public colleges, universities or districts
Proof
What we have built that this rests on.
57 featured AI case studies: AI products and brownfield AI builds, each written up on our Work page.
Transcripts U.S.
Government, Legal & Defense · Legal transcript marketplace
Attorneys receive deposition transcripts that even the marketplace cannot read
The marketplace could once read every transcript it held; now each file is encrypted in the agency's browser and opens only in the paying attorney's.
Dental clinical documentation AI
AI engine · Review and approve
AI clinical documentation inside the dentist appointment workflow
Live transcription, patient context and AI-drafted clinical notes with dentist review and approval.
Our own product
B2B Software · AI support assistant
Support chats answered from each company's own content, with handoff to a person
Bots that answer from the wrong content lose visitors. Each chatbot in our assistant answers from its own knowledge base and hands off to an agent.
Read next: K-12 software vendors can ship AI without needing student data
How it works
Three ways to start, each at a fixed price.
K-12 vendors usually start with Docently for teachers and parents on their real help center, on synthetic data, because it doesn't need student records.
EdTech Product Review · 30 minutes, no chargeStart here. We look at your product with you, agree the buyer outcome you want, and tell you which of the three below fits.
Book a 30-minute Product ReviewNo AI yet, and a module fits
Build Sprint
$10,000 fixed3 weeks
Pick it when: One of our modules delivers the outcome you want.
- One buyer outcome (2–3 related capabilities) working in your staging, behind a feature flag
- Pull requests to your repo, built on your catalog and synthetic or de-identified data
- Quality and safety evals, the cost to serve and a packaging recommendation
- A fixed-price quote for production
Something new, or a plan first
Planning Sprint
$5,000 fixed2 weeks
Pick it when: You need something our modules don't cover, or want a plan before you build.
- Where AI fits across your product, including beyond our modules
- A prioritized capability map, with what each one depends on
- A readiness review of your architecture, data and permissions
- A fixed-price quote to build it and take it to production
AI already built or tried
AI Scorecard
$5,000 fixed2 weeks
Pick it when: You've already built or tried an AI feature in your product, live or not.
- One AI feature you've built, tested in staging on 50 of your own cases
- Data-safety and misuse tests, and an accessibility pass on the AI screens
- Cost per learner and a packaging recommendation
- A scorecard, ranked fixes, draft security answers and a fixed quote
Not a compliance audit or certification.
Production, at a fixed quote
We take what your Sprint built or planned live for your customers, by pull request, with no standing production access. It typically includes load testing at your peak and a spend cap per institution. Your Sprint or Scorecard fee counts toward it.
After go-live, optional support
The product is finished and yours to run. If you want us to stay on: a named lead engineer, a monthly quality and cost report, testing before any model change, and more capabilities, each at its own fixed quote.
Stop after any Sprint and keep what you got.
How a Build Sprint runs
- In the setup week we map your integrations and agree what the Sprint touches.
- We follow your coding standards, tests and CI; your engineers review and merge every pull request.
- Half at signature, half when the Sprint Pack is delivered.
- Your time: about 2 to 3 hours a week from a product owner, plus an engineer to review pull requests.
Product improvements you can measure
What we agree to measure: quality and cost on test sets in the Build Sprint, adoption and outcomes once it is in production, so the decision rests on your numbers, not ours.
Teacher and parent help
Questions answered without a ticket at term start
Admin answers
Report requests closed without engineering time
Accessible product
WCAG 2.1 AA issues closed per release
We set the success measures with you in the setup week.
Built for education data
Controls your customers' security reviews ask about.
Each control is a design fact about how the module is built and how we work, not a compliance claim.
Works with what you run
Reads catalog, courses, rosters and gradebook through the APIs and roles your product already has.
Synthetic data in Sprints
Sprint work uses synthetic or de-identified data and ships as pull requests to your repo.
Cited, and staff approve
Answers cite their source; anything that changes a grade, application or record waits for staff.
We work within your FERPA, COPPA, accessibility, security and institutional requirements. Compliance depends on the complete product, contracts, policies and operating environment; Datics does not present software engineering alone as legal certification.
How we handle student dataQuestions we hear on the first call
Straight answers before you book.
Do you need access to student records?
No. Sprints use synthetic data, production student data stays in your US cloud under your controls. In production we work only through access you grant, and you can revoke it at any time.
What about students under 13?
Features for users under 13 are designed with COPPA's parental-consent requirements in mind; your counsel decides how your agreements apply.
Can a district switch the AI off?
Yes. It's designed to be switched on or off per district, with data settings their admins control.
Who do you work for?
You, the vendor. We work as your subprocessor and sign the data terms your district agreements require of anyone working on your product.
See AI in your K-12 product, built on synthetic data.
Bring one product, workflow or AI feature. In 30 minutes we tell you which of the three ways to start fits, what it would cost to serve and what your customers' security review will ask.
Calls run in US Central time. No generic AI presentation: we discuss your product, users and production constraints.