What Procurement Should Demand in an Accessibility AI Contract: A Due-Diligence Checklist

This is the document to attach to every AI-accessibility RFP a procurement office issues this year. Each requirement below is grounded in either the DOJ April 2026 Interim Final Rule preamble — analysed in reading the IFR — or the recurring pattern in recent OCR higher-ed resolution agreements, synthesised in the OCR-pattern article. The deadline math making the procurement question urgent is set out in the 2027/2028 math. The full framework these requirements sit inside is the defensibility standard; this article translates it into contract language.

Eleven requirements follow. Each is non-negotiable for vendors selling defensibility under the post-IFR regulatory record. Vendors who decline to commit to any of them in writing are vendors whose product cannot serve the procurement purpose, regardless of scanner-conformance claims.

1. Human-review accuracy SLA

Requirement. The vendor commits to a measurable accuracy floor on AI-proposed fixes that are accepted by trained human reviewers without modification, evaluated against an institutionally-defined sample of representative content. Scanner-score uplift is not an acceptable substitute metric.

Rationale. Scanner-score SLAs reward gaming the scanner; reviewer-acceptance SLAs reward fixes that survive a domain expert. See audit-trail defensibility.

Sample clause. "Vendor warrants that AI-proposed fixes will achieve a Human-Reviewer Acceptance Rate of no less than {X}% across a quarterly sample of {N} representative documents drawn from Customer's content corpus, evaluated by Customer-designated trained accessibility reviewers. Failure to achieve this rate over two consecutive quarters constitutes a material breach."

2. Audit-trail export

Requirement. Per-document audit trail exportable in a machine-readable format (JSON or CSV — not PDF), covering at minimum: document identifier, scan timestamp, issues flagged, fix proposed, reviewer name, review timestamp, action taken, fix-verification result.

Rationale. This is the artefact OCR investigations request. PDF reports are designed for the human consumer; the regulator wants a machine-readable record that can be queried, joined to other institutional records, and audited at scale. See audit-trail defensibility.

Sample clause. "Vendor shall provide Customer with on-demand export of the per-document audit trail for any document or set of documents in Customer's account, in JSON or CSV format, containing at minimum the eight fields specified in Schedule [A]. Export shall be available within 24 hours of Customer request."

3. Inference-location disclosure

Requirement. Written disclosure of where inference physically executes, what subprocessors are involved, what is logged at the inference endpoint, and whether the institution's executed data-protection agreement covers the full data flow.

Rationale. Many AI accessibility vendors subprocess inference through third-party foundation-model providers whose terms of service govern what happens to submitted content. If the institutional DPA does not cover that endpoint, a complaint or breach investigation has a contract gap to address. See FERPA, cloud inference, and data sovereignty.

Sample clause. "Vendor shall disclose, in Schedule [B], the country and operator of any infrastructure on which inference against Customer content executes; all subprocessors involved in the inference path; the retention period for any logs of submitted content; and confirmation that the data flow is fully covered by the executed Data Protection Agreement between Vendor and Customer."

4. Indemnification for AI-introduced errors

Requirement. Vendor accepts liability for accessibility issues the AI affirmatively introduces during remediation, distinct from issues it fails to fix. The two failure modes are categorically different and warrant separate indemnification language.

Rationale. Hallucinated alt text and false-positive structural fixes are new harms the vendor's product caused, not pre-existing harms it failed to address. See hallucinated alt text as a Section 504 risk.

Sample clause. "Vendor shall indemnify Customer against any third-party claim arising from accessibility defects in Customer content that were introduced by Vendor's AI-generated remediation, separately from and in addition to indemnification for defects pre-existing the engagement."

5. Exit clause with full audit-trail export

Requirement. On contract termination, vendor delivers within a defined window all per-document audit-trail records in a machine-readable format the institution can ingest into a successor system. No data is retained beyond a documented destruction window.

Rationale. The audit trail outlasts the vendor relationship — it is the institution's evidence in any future investigation, regardless of which vendor produced it. A vendor whose exit clause does not address audit-trail portability has built a switching-cost moat at the institution's expense.

Sample clause. "Within 30 days of contract termination for any reason, Vendor shall deliver to Customer the complete per-document audit trail in JSON and CSV formats. Vendor shall destroy all retained copies within 60 days of delivery and provide written attestation of destruction."

6. Model-change notification

Requirement. Vendor notifies Customer with at least 30 days' lead time before substituting the underlying foundation or vision model used in inference. The accuracy SLA in Requirement 1 re-baselines on the new model.

Rationale. Model changes change accuracy distributions. An SLA pegged to a model the vendor swaps out without notice is an SLA whose evidentiary basis silently disappears.

Sample clause. "Vendor shall provide Customer with at least 30 days' written notice prior to any substitution of the foundation model, vision model, or other inference component materially affecting accuracy. Following any such substitution, the Human-Reviewer Acceptance Rate target in §1 shall be re-evaluated against a fresh sample for the subsequent quarter."

7. FERPA subprocessor flow-down

Requirement. All subprocessors handling Customer content are bound to the same FERPA school-official-exception conditions Customer has imposed on Vendor.

Rationale. A vendor's compliance does not extend to its subprocessors unless the contract makes it. Without flow-down, the institution's FERPA posture stops at the vendor boundary. See FERPA, cloud inference, and data sovereignty.

Sample clause. "Vendor shall require, by written contract, that all subprocessors processing Customer content abide by the same restrictions on use, redisclosure, and retention as Vendor under this Agreement, and shall provide Customer with copies of those subprocessor contracts on request."

8. Data-residency commitment

Requirement. A binding data-residency clause specifying the country (or, where applicable, region) in which Customer content is processed and stored. Marketing claims that do not appear in the contract do not bind.

Rationale. State-level data-protection regulations and international student-content considerations frequently require residency commitments stricter than FERPA's federal floor.

Sample clause. "Customer content shall be processed and stored exclusively within {jurisdiction(s)}. Any change to this commitment shall require Customer's prior written consent and shall constitute a material amendment."

9. Training-data exclusion

Requirement. Customer content is not used to train or improve Vendor's or any subprocessor's models. The exclusion is contractually binding, not policy-stated.

Rationale. Training-data inclusion is the default at most foundation-model providers' lower service tiers. Without an explicit exclusion clause, institutional content may be incorporated into future model versions.

Sample clause. "Vendor shall not use Customer content, in whole or in part, to train, fine-tune, evaluate, or otherwise improve any machine-learning model — Vendor's own or any subprocessor's — without Customer's prior written consent."

10. Named subprocessors

Requirement. Subprocessors are identified by name in the contract, not authorised generally.

Rationale. A general "subprocessors permitted" clause does not produce a written record of where institutional content goes. The named-subprocessors approach makes the data flow auditable.

Sample clause. "All current subprocessors are listed in Schedule [B]. Vendor shall provide Customer with at least 30 days' written notice and opportunity to object before engaging any new subprocessor."

11. Audit-cooperation in regulatory investigations

Requirement. Vendor cooperates in good faith with any OCR or DOJ investigation involving Customer's accessibility programme, including providing copies of relevant audit-trail records and inference-pipeline documentation on subpoena or formal request.

Rationale. A complaint investigation may require evidence that lives in vendor systems, not Customer systems. Cooperation cannot be assumed; it must be contractually committed.

Sample clause. "In the event of any investigation or inquiry by the U.S. Department of Education Office for Civil Rights, the Department of Justice, or any state regulatory body concerning Customer's accessibility programme, Vendor shall provide reasonable cooperation, including production of audit-trail records, inference-pipeline documentation, and relevant subprocessor agreements within 14 days of Customer request."

---

These eleven items are derived from the procurement gaps the IFR's preamble and the recent OCR settlement record have identified. They are the minimum the regulatory record now supports, and the contract clauses that codify them are what distinguish vendors selling defensibility from vendors selling scores.

Aelira was built around this configuration: a human-in-the-loop review queue producing the audit-trail records Requirement 2 specifies, self-hosted inference closing the data-flow gaps in Requirements 3, 7, 8, and 10, and AI-proposed remediation paired with reviewer accept-reject-override actions satisfying Requirements 1, 4, and 5. If you would like the editable version of this checklist as a starting point for your next vendor evaluation, reach the team. The template is shareable inside your procurement workflow and carries no obligation to proceed to a vendor evaluation.