AI

Implementing AI in education well means running it under an AI governance framework: an operating model in which every AI use is listed, every use is classified by risk, high-risk uses pass a human review before they reach students, vendors are held to written terms, and the whole program is monitored and reported on a fixed schedule. Industry frameworks supply most of that model. The National Institute of Standards and Technology (NIST) AI Risk Management Framework, ISO/IEC 42001, ISACA’s COBIT and the SOC 2 reports vendors already produce can be combined so that one set of controls answers to all of them. The need is plain. In spring 2025, 54 percent of students and 53 percent of English language arts, math and science teachers said they used AI for school, yet only 45 percent of principals reported school or district policies or guidance on its use (RAND, September 2025). By August 2026, 35 states and Puerto Rico had issued official guidance or policy on AI in K–12 schools, according to a tracker kept by AI for Education.

This guide on how to implement AI in education sets out ten steps that a school district, a school or a college can follow to implement AI, in order, and shows which framework does the work at each step. It is written for superintendents, school board members, college presidents and provosts, chief information and technology officers, privacy and procurement officers, internal auditors and the teachers and faculty who will live with the results, with a short section for families. It covers U.S. K–12 schools and colleges, with notes on the European Union’s AI Act for institutions whose AI is used in Europe. It is not legal advice. For the broader picture of how AI is used in classrooms, see edCircuit’s AI in Education: A Guide for Schools and Colleges; for classroom practice, see How to Implement AI in the K–12 Classroom.

Updated October 2026.

In this guide

• Foundations: Step 1: Governance and ownership · Step 2: Inventory every AI use · Step 3: Classify data and risk
• Frameworks and vendors: Step 4: Choose and crosswalk frameworks · Step 5: Vet vendors and SOC 2 reports
• Putting it to work: Step 6: Policy encoded in systems · Step 7: Pilot with evidence · Step 8: Train people
• Keeping it running: Step 9: Monitor, audit and report · Step 10: Respond to incidents · A 12-month plan
• People: Questions to ask · Families

Step 1: Set governance and ownership

The first step is to decide who is accountable for AI and where decisions about it are made. In most institutions AI arrives before anyone owns it: a teacher signs up for a tool, a department turns on a feature in software it already licenses, a vendor adds a chatbot to an admissions page. Governance gives those decisions a home.

Two bodies are usually needed.

• The governing board and its committees. A school board, a board of trustees or a board of regents sets the institution’s appetite for AI risk, approves the policy that states its principles, and receives regular reports. Where a board already has an audit, risk or technology committee, AI oversight belongs there rather than in a new body.
• A cross-functional AI council. A working group, often chaired by the chief information officer together with the chief academic officer in a district or the provost’s designee at a college, reviews new uses, approves or declines them, and tracks incidents. Membership should reach beyond technology: curriculum and assessment, special education or disability services, privacy and legal counsel, procurement, internal audit or risk, student services, communications, and teachers or faculty. Colleges that conduct research add their institutional review board. Student representatives, where appropriate, can describe how AI is actually used.

The frameworks agree on this step. The NIST AI Risk Management Framework (AI RMF) is organized around four functions, Govern, Map, Measure and Manage, and treats Govern as “a cross-cutting function” that informs the other three. One of its outcomes, Govern 2.1, calls for roles, responsibilities and lines of communication on AI risk to be documented and clear throughout the organization. ISACA’s COBIT 2019 places the same duty in its governance objective EDM01, Ensured Governance Framework Setting and Maintenance, which ISACA’s 2025 white paper on AI describes as establishing a framework that “clarifies roles and maintains organizational accountability.” ISO/IEC 42001 includes an AI policy among the requirements of its management system.

Many organizations are not there yet. In ISACA’s 2026 AI Pulse Poll of more than 3,400 digital trust professionals, only 38 percent said their organization had a formal, comprehensive AI policy, and 38 percent were confident in their board’s understanding of and action on AI risks (ISACA, May 5, 2026). The respondents work across industries, not only in education, but schools and colleges face the same gap. In my work with boards, the question is no longer whether to use AI. It is how to use it at scale without taking on risk the board cannot price, and that question can only be answered by a body that owns it.

A practical test for Step 1: the council has a written charter, a published meeting schedule and a named chair; the board knows which committee receives AI reports and when. edCircuit’s coverage of district governance:

• AI and Governance in School Districts
• What District Leaders Must Do in the AI Era
• AI Guardrails Are Reshaping K–12 Schools

Step 2: Inventory every AI use, including AI inside existing tools

The second step is a complete list of where AI is already in use or proposed, because most of it was never announced. The inventory has to include AI features inside products the institution already licenses, not only new tools bought as “AI.” ISACA’s Artificial Intelligence Governance Brief warns that unplanned AI adoption can occur “with little to no oversight, particularly given the availability of AI solutions included in products already in use,” and its COBIT white paper notes that AI features are embedded in commercial off-the-shelf software and common search engines that are likely already in use. In schools and colleges, that means the learning management system, the student information system, writing and tutoring tools, proctoring software, translation services, admissions and advising platforms, and the office productivity suite.

The AI RMF names the task directly. Govern 1.6 calls for “mechanisms … to inventory AI systems,” resourced according to the organization’s risk priorities, and NIST’s Generative AI Profile adds that organizations should enumerate their generative AI systems for the inventory and consider recording data provenance and other details in each entry (NIST AI 600-1). For an education institution, each entry should record at least:

• The tool, the vendor and, where known, the underlying model and who provides it
• What the AI does, for which grades, courses or offices, and whether students use it directly
• The business owner, a named person rather than a department
• The data classes it touches (see Step 3)
• Its risk tier (see Step 3)
• Contract status: whether a data privacy agreement is signed, whether a SOC 2 report has been received and reviewed, and whether the vendor has disclosed its model and change policy (see Step 5)

The inventory can begin as a spreadsheet. What matters is that it is complete, has an owner, and is the only list. A survey of department heads and principals, a review of single sign-on and app-store logs, and a review of purchase orders will usually find more AI than anyone expected. “You cannot govern what you cannot list,” as Stephen Gilfus puts it in his advisory work on AI governance. Two edCircuit articles describe this starting point: Where to Begin with AI in K-12, whose first phase includes identifying tools that already use AI, and Your School’s AI Policy May Already Be Outdated, on AI that arrives inside platforms a district approved before the feature existed.

Step 3: Classify data and risk

The third step attaches two labels to every entry in the inventory: what kinds of data the use touches, and how much harm it could do. Together they decide how much review a use needs.

Data classes. Without named classes, people act on defaults, and student work can end up treated as a vendor’s product data. A simple scheme with four classes, drawn from Gilfus’s field note on AI-assisted learning, works in schools and colleges alike:

The rules are defaults the AI council can tighten. Each class should also say who may opt in or out, and where the class may be processed.

Risk tiers. The AI RMF’s Map function begins with context: Map 1.1 asks organizations to understand and document a system’s intended purposes, potentially beneficial uses and the settings in which it will be deployed. NIST’s Generative AI Profile then lists 12 risks that generative AI creates or makes worse. Several bear directly on schools: confabulation, the production of “confidently stated but erroneous or false content”; data privacy; harmful bias, including performance differences between groups or languages; human-AI configuration, which includes over-reliance and emotional entanglement; information integrity; obscene and abusive content, including synthetic images of children; and value chain and component integration, the risk of untraceable third-party components inside a product.

The EU AI Act offers the clearest list of education uses that deserve the highest tier. Annex III of Regulation (EU) 2024/1689 classifies as high-risk AI systems intended to be used in education and vocational training to:

• Determine access or admission, or assign people to institutions
• Evaluate learning outcomes, including when the results steer a person’s learning
• Assess the appropriate level of education a person will receive or can access
• Monitor and detect prohibited behavior of students during tests

The Act separately prohibits AI systems that infer the emotions of people in education institutions, except for medical or safety reasons (Article 5(1)(f)). U.S. institutions outside its reach can still use the list as a guide. A three-tier scheme is enough for most:

Low-risk uses should move quickly; high-risk uses should slow down on purpose. For the decisions that should stay with people regardless of tier, see edCircuit’s AI in Schools: What Technology Should Never Decide.

Step 4: Choose an AI governance framework and crosswalk the others

The fourth step is to choose one framework as the backbone of the program and map the others to it, so that each control is designed and tested once and reported many times. Institutions rarely face a single framework. A district may already use COBIT for IT governance, buy from vendors that hold SOC 2 reports, answer to state guidance and, for a college with students in Europe, the EU AI Act. The frameworks are different kinds of document, and knowing which kind each is prevents a common mistake: treating a law, a voluntary framework and an audit report as interchangeable.

For most U.S. districts and colleges, the practical choice of a responsible AI framework is the NIST AI RMF as the backbone, with its Generative AI Profile for generative tools; COBIT where the institution already governs IT with it; and ISO/IEC 42001 where an institution wants a formal management system. The documents are designed to be mapped to one another. NIST’s AI Resource Center publishes crosswalks between the AI RMF and other standards, including one to ISO/IEC 42001, which maps, for example, Govern 1.1 on legal and regulatory requirements to the standard’s clause on understanding the organization and its context and to its AI policy controls (NIST AI RMF to ISO/IEC 42001 crosswalk). NIST notes that listing a crosswalk does not mean either document fully covers the other. ISACA’s white paper does the same work for COBIT, linking trustworthy-AI principles to objectives such as EDM03 and APO12 for risk, BAI06 for changes to AI systems, APO14 for data, MEA01 for performance monitoring and MEA03 for compliance with external requirements.

The crosswalk is the institution’s own document: a table with one row per control, such as “every Tier 3 use has a named human decision-maker,” and columns showing which clause of each framework it satisfies, who owns it and where its evidence is kept. Gilfus describes the aim as being audited once and reported many times, rather than the other way around. Districts that want a shorter AI readiness assessment as a starting point can also use the K-12 Generative AI Readiness Checklist that CoSN and the Council of the Great City Schools released in October 2023, which groups its questions into six areas: executive leadership, operations, data, technology, security and risk management (CoSN).

Where the EU AI Act applies. The Act covers providers that place AI systems on the EU market wherever they are based, deployers located in the EU, and providers and deployers in other countries “where the output produced by the AI system is used in the Union” (Article 2). A U.S. college with a campus or online students in Europe should ask counsel whether it is in scope. Its dates have moved. The prohibitions and the AI literacy duty have applied since February 2, 2025, the general-purpose AI rules since August 2, 2025 and the transparency rules from August 2026; after a political agreement to simplify the Act, the European Commission says the rules for high-risk uses in areas including education will “apply from 2 December 2027,” instead of August 2, 2026. Under the Act as adopted in 2024, deployers of high-risk systems must assign human oversight to people with the competence, training and authority to exercise it, keep automatically generated logs under their control for at least six months, and tell people when a high-risk system makes or assists decisions about them (Article 26); public bodies must also assess the impact on fundamental rights before deployment (Article 27).

Disclosure: Stephen Gilfus serves on ISACA’s board of directors.

Step 5: Vet vendors, read their SOC 2 reports and write governance into contracts

The fifth step applies the framework to vendors, because in schools and colleges most AI is bought rather than built. A vendor review has three parts: the evidence the vendor provides about its controls, the controls the institution must run itself, and the contract.

What a SOC 2 report is. A SOC 2 report is an independent CPA’s report on a service organization’s system and its controls over one or more trust services categories: security, availability, processing integrity, confidentiality and privacy. The AICPA’s guide to these examinations describes two kinds (AICPA SOC 2 guide, chapter 1):

• Type 1 covers the description of the system and whether controls were suitably designed as of a point in time.
• Type 2 also covers whether controls operated effectively throughout a period, and includes a description of the auditor’s tests and their results.

For SOC 2 compliance from a school’s side, the Type 2 report is the useful one, because it shows whether controls worked over months rather than whether they existed on one day. The report is not a certificate, and reading it is a task, not a formality. A district or college should check:

• Scope. Does the system described include the AI product being bought, and which trust services categories were examined? A report on a vendor’s billing system says nothing about its tutoring tool.
• Period and opinion. Is the period recent, and did the auditor report exceptions or qualify the opinion?
• Subservice organizations. The guide explains that a description may include a subservice organization’s controls or exclude them, the “carve-out” method. Many AI products depend on an outside model provider and a cloud host; if those are carved out, the report does not cover them, and the institution needs separate assurance about them.
• Complementary user entity controls. Readers of a SOC 2 report are expected to understand the complementary user entity controls, the controls the vendor assumes its customers operate, and how they interact with the vendor’s own. Typical examples are removing accounts when staff leave, reviewing who has administrative access, and configuring data-sharing settings. If the institution does not run those controls, the vendor’s controls may not achieve what the report describes.
• The auditor. The AICPA has said it is looking into anonymous allegations about the practices of a compliance vendor that offers SOC services, and has warned about “fast and easy” SOC engagements (AICPA). Institutions should confirm that the report was issued by a licensed CPA firm.

Gilfus’s rule of thumb from IT audit applies: a SOC report the institution cannot map to its own controls is “a comfort blanket, not assurance.” The mapping belongs in the crosswalk from Step 4.

What SOC 2 does not cover. A SOC 2 report addresses security and related categories. It does not say how accurate a model is, whether it is biased, which model version answered a student’s question, or whether student work is used for training. NIST’s Govern 6.1 calls for policies that address AI risks from third parties, and Manage 3.1 for AI risks and benefits from third-party resources to be regularly monitored. Those questions go into the contract.

Contracts as governance. Contracts translate an institution’s choices into vendor behavior. For any tool that processes Student Content or Student Record data, or that produces grades, feedback or recommendations, the contract should require:

• A model bill of materials. The model family and version, any fine-tuning, safety filters, where requests are processed, and the vendor’s change policy.
• Change notices and version control. Advance notice of material changes with effective dates, a test environment, and the option to roll back or pin a version for a grading period. A vendor can swap the model behind a feature overnight, and the same prompt can then produce different feedback.
• Per-request logging. A record of which model handled which request, with time and data class, kept at least for a term and available for audit.
• No training on student data without explicit, revocable consent at the institutional level, covering the vendor’s subprocessors as well.
• Deletion, export and incident terms. Return and deletion of data on request and at contract end, a defined notification window for security and AI incidents, and audit rights.
• Equitable access. Institution-wide pricing for features that affect assessment, so that access does not depend on which students can pay.

Student privacy law. Contracts must also satisfy federal law. Under FERPA, a contractor may receive education records without consent as a “school official” only if it performs a service the institution would otherwise use employees for, is “under the direct control of the agency or institution with respect to the use and maintenance of education records,” and is bound by the rules on use and redisclosed (34 CFR 99.31(a)(1)(i)(B)). For children under 13, the Federal Trade Commission’s amended COPPA Rule took effect on June 23, 2025, and regulated companies had until April 22, 2026, to comply (Federal Register, April 22, 2025). The FTC stated in the rule that disclosing a child’s personal information to third parties to train or otherwise develop AI technologies is not integral to a service and requires separate parental consent, and the rule requires operators to keep a written data retention policy. The FTC did not finalize its proposed provisions on school authorization, citing possible changes to FERPA regulations, so districts should follow current FTC and Department of Education guidance on when a school may act for parents. State student-privacy laws add requirements; this guide did not review them, and counsel should.

edCircuit’s procurement coverage includes AI Procurement for Schools: 10 Questions to Ask, COPPA in Schools: What Educators Must Know and AI in K–12 Procurement Operations Today.

Step 6: Write policy and encode it in systems

The sixth step turns decisions into rules people meet at the moment they act. It has two layers. The board adopts a short policy of lasting principles: student data is protected, people remain responsible for decisions about students, AI use is disclosed, and access is equitable. Administrators then maintain an operational handbook with the details that change often: the approved-tool list, assignment labels, disclosure forms, the vendor-review process and training requirements. edCircuit’s Why Every School District Needs an AI Operational Handbook explains the difference between an AI policy for schools and a handbook and what a first edition should contain.

The federal government has left most of these choices to states and institutions. In its April 2026 final priority on AI, the Department of Education responded to commenters who asked for federal safety and privacy requirements that it believes how best to ensure safety and communicate about technology use “is optimally decided at the state and local level and declines to enact requirements at the federal level.” The same notice says the department’s July 2025 guidance on federal grant funds for AI indicates that stakeholders, especially parents, should understand how systems function and take part in decisions about adopting them.

A policy that lives only as a PDF does not govern behavior. Gilfus puts it in one line: “If the rule isn’t in the workflow, it isn’t real.” Encoding policy means configuring the systems people already use:

• Course and assignment templates. Learning management system templates that carry an AI-use statement, and assignment types that label the expected role of AI, such as prohibited, limited, cited or required, so students do not have to guess which rule applies.
• Submission metadata. A short field in which students say which AI tools they used and for what steps, with any generated text attached.
• Routing rules. Settings, or at first a manual process, that decide which data classes may go to which approved models, with logging and an opt-out.
• Allow and deny lists. Approved tools enabled through single sign-on; unapproved ones blocked or flagged; versions pinned for a term where grading depends on them.
• Messages that teach. When a request is blocked, an explanation of the rule and what is allowed instead.

Equity belongs in this step, as a configuration choice rather than an afterthought. If an AI feature that affects assessment comes only in a premium tier, in English, or on newer devices, some students will have it and others will not. Institution-wide licensing, multilingual support, low-bandwidth modes, accessible design and supervised access on campus are decisions made in configuration and contracts. For communicating classroom rules to students and families, see AI Rules for Schools: A Back-to-School Guide.

Step 7: Pilot with evidence

The seventh step tests Tier 2 and Tier 3 uses on a small scale before they spread, and measures learning, not only satisfaction. A pilot is an evaluation with a defined question, not a soft launch.

The evidence on AI and learning is mixed, which is the reason to pilot. Students and families are worried about one kind of harm. In RAND’s 2025 surveys, 61 percent of parents, 48 percent of middle school students and 55 percent of high school students agreed that greater use of AI will harm students’ critical-thinking skills, compared with 22 percent of district leaders (RAND). By December 2025, 62 percent of middle school, high school and college students in RAND’s American Youth Panel used AI for homework, and 67 percent said using AI for schoolwork harmed critical thinking (RAND, March 17, 2026). Studies of AI tutors designed to teach, summarized in edCircuit’s AI in Education guide, have found real gains; studies in which students simply received answers have found later losses. Design and use decide which result an institution gets.

A sound pilot:

• Starts with a problem, not a product. Define what should improve and how it will be measured before choosing a tool.
• Covers different kinds of work. Three to five pilots across assessment types, such as writing, problem solving and design, with teachers or faculty who opt in.
• Compares. Sections using the tool and sections that are not, on the same assignment pattern and rubric, read for direction rather than over-interpreted.
• Measures learning and harm. Rubric results, revision depth, persistence, incidents, accessibility problems and differences between student groups. NIST’s Measure function and the Generative AI Profile’s emphasis on pre-deployment testing apply here.
• Holds high-risk uses back. New Tier 3 deployments, such as automated grading, advising or proctoring, wait until the vendor provides model transparency and logs.
• Ends with a decision. Scale, revise or stop, recorded by the council. Leaders should be willing to walk away.

The Department of Education took a similar view in its April 2026 priority, agreeing with commenters that AI adoption “should not be evaluated solely by efficiency or automation metrics,” but by its demonstrated impact on student engagement, learning progress and readiness. For a phased district approach, see edCircuit’s AI Adoption in Schools: A Roadmap for K–12 Success.

Step 8: Train people for their roles

The eighth step prepares the people who will apply the rules. Training has lagged use. As of spring 2025, 35 percent of district leaders said they provided students with training on AI, and more than 80 percent of students said their teachers had not explicitly taught them how to use AI for schoolwork (RAND). Across industries, 33 percent of ISACA’s 2026 respondents said their organizations trained all employees on AI.

The EU AI Act makes AI literacy a legal duty for organizations in its scope: Article 4, as amended in July 2026, requires providers and deployers to take measures that support the AI literacy of staff and others who operate and use AI systems on their behalf, without mandating a specific level. U.S. institutions can borrow the principle without the obligation. Training should be role-based, not one annual click-through for everyone:

• Teachers and faculty: the approved-tool list, which data may never be entered, how to check output for errors and bias, assignment labels and disclosure, and why a detector’s score is not proof of cheating.
• Counselors, advisors and student services: consent language, summary templates that separate student, staff and machine voices, and the limits of predictive alerts.
• Special education and disability services: accommodations, accessibility testing, and the rule that AI never decides eligibility or services.
• Administrators and board members: the risk tiers, the reporting cadence and their own decision rights.
• Technology, procurement and audit staff: model bills of materials, SOC 2 reports, logging, change control and AI-specific audit. ISACA offers AI audit, security and risk training and a credential, Advanced in AI Audit, for experienced IT auditors (ISACA).
• Students: AI literacy by grade, including when AI use helps learning and when it substitutes for it.

edCircuit’s AI Training for Teachers: Beyond Prompts and Tools covers professional development, and AI Literacy for Students: A Grade-by-Grade Guide covers what students should learn at each stage.

Step 9: Monitor, audit and report on one cadence

The ninth step keeps the program honest after launch. AI systems change after they are deployed, through vendor updates, new data and new uses, so a review at purchase is not enough. The AI RMF’s Manage 4.1 calls for post-deployment monitoring plans that include ways to capture input from users, “appeal and override, decommissioning, incident response, recovery, and change management,” and Govern 1.5 calls for ongoing monitoring and periodic review with defined roles and frequency.

An audit approach. Internal audit, or an outside auditor in a smaller district, tests whether the controls in the crosswalk work. COBIT supplies the structure: MEA01 for performance and conformance monitoring, MEA02 for the system of internal control and MEA03 for compliance with external requirements, as ISACA’s white paper on AI maps them. ISACA’s Artificial Intelligence Audit Toolkit is a library of AI controls derived from selected control frameworks and laws, organized by the AI lifecycle, with assessment guidance for auditors. A first AI audit in a school system might sample the inventory against reality, test whether Tier 3 uses have named human decision-makers and working appeal paths, check that vendor change notices were received and reviewed, and confirm that complementary user entity controls from vendors’ SOC 2 reports are actually operated.

One cadence. Gilfus recommends that AI governance run on the same rhythm as cyber and audit work: monthly at the working layer, where model owners, the council and support staff review incidents, change notices and pilot results; quarterly at the board’s audit, risk or technology committee; and annually at the full board, with one integrated report. Running three programs on three calendars produces three contradictory stories.

A report a board can act on. As Gilfus writes, a board cannot act on a scatterplot; it can act on a trend line and a threshold. A one-page quarterly report should contain:

• Position and change: the current state of the program and what changed since the last meeting
• The inventory by tier: how many uses in each tier, and what was added, paused or retired
• Incidents: privacy exposures, harmful or biased outputs and model failures, with time to resolve
• Learning signals: results from pilots by course type, not individual courses
• Vendor and model drift: change notices received and their effects
• Decisions requested: what the committee is asked to approve, with the options considered

Every figure should link to its evidence: a control test, an incident record, a pilot result or a vendor’s SOC 2 report. For institutions in the EU AI Act’s scope, the logs kept under Article 26 are part of that evidence.

Step 10: Respond to AI incidents

The tenth step prepares for the day an AI system causes harm. An AI incident is not always a security breach. It may be a tutoring tool giving harmful advice, a writing assistant exposing a student’s essay to another user, a biased placement recommendation, a model update that changes grading feedback mid-term, a prompt-injection attack, or a manipulated image of a student. Gilfus advises keeping AI incident response distinct from cyber incident response while feeding the same records and reporting.

The frameworks set the expectations. The AI RMF’s Manage 4.3 calls for incidents and errors to be communicated to relevant parties, “including affected communities,” with processes for tracking, responding and recovering that are followed and documented. Govern 6.2 calls for contingency processes for failures or incidents in third-party data or AI systems, and incident disclosure is one of the Generative AI Profile’s four primary considerations. Readiness is uneven: in ISACA’s 2026 poll, 56 percent of respondents did not know how long it would take to halt an AI system in a security incident, and 39 percent did not know whether their organization had a documented process for shutting down or overriding AI systems.

An AI incident plan for a school or college should name:

• Who can pause a tool, and how quickly: the authority to suspend a feature, roll back a model version or disable an integration for a term
• Severity levels tied to data classes and risk tiers, so that exposure of Student Record data triggers a different response from an inaccurate lesson summary
• Notification: who tells students, families, staff, the board and, where law requires, regulators, and on what timeline; contract terms from Step 5 govern what the vendor must tell the institution
• Correction: how a decision influenced by a faulty system is reviewed and, where needed, reversed, and how records are corrected
• Learning: a review after each significant incident that changes routing rules, contracts or training

Tabletop exercises, in which the council walks through a realistic scenario, test the plan before it is needed. For deepfake incidents specifically, see edCircuit’s AI Deepfakes: The New School Safety Threat.

A 12-month implementation plan

The ten steps overlap in practice. A one-year plan that fits a board’s calendar, adapted from the sequence Gilfus recommends to boards and CIOs, looks like this:

The aim is to make governance boring and repeatable, so that each new AI use lands inside known guardrails instead of starting a new debate. Gilfus sets out the longer argument, including the reference architecture behind this plan, in his field note The Governance Gap in AI-Assisted Learning.

Questions to ask about implementing AI in your institution

For board members, superintendents, presidents and other leaders

• Which board committee receives AI reports, how often, and who signs them?
• Do we have a complete inventory of AI uses, including AI features inside software we already license, and who owns it?
• Which of our AI uses are Tier 3, such as admission, placement, grading, proctoring or discipline, and does each have a named human decision-maker and an appeal path?
• Which framework is the backbone of our AI governance framework, and does our crosswalk show which control satisfies which requirement?
• For each vendor that handles Student Content or Student Record data, have we read a current SOC 2 Type 2 report, checked what it carves out, and confirmed that we operate the controls it expects of us?
• Do our contracts require a model bill of materials, change notices, version pinning, per-request logs and a ban on training with student data?
• Who can pause an AI tool today, and how long would it take?
• Are we measuring whether AI improves learning, or only whether people like it?
• Does any student lack access to an AI feature that affects assessment because of cost, language or device?

For teachers and faculty

• Which AI tools are approved for my courses and students, and what information may never be entered into them?
• Does each assignment tell students whether AI is prohibited, limited, to be cited or required?
• Do my rubrics reward process, such as drafts, revision and reflection, so that I can see how students worked?
• Do I check AI-generated materials for errors, bias and accessibility before students see them?
• If I suspect misuse, do I gather drafts and talk with the student rather than relying on a detector’s score?
• Whom do I tell when a tool behaves differently from last week, gives a harmful answer or exposes student work?

What should families know?

Families have a right to know how AI is used with their children and what happens to their children’s information. Practical questions to ask a school or college:

• Which AI tools does my child use, for what purpose, and are they approved by the school or district?
• What happens to my child’s work and data? Is it used to train the company’s AI, how long is it kept, and can it be deleted?
• Does AI influence decisions about my child, such as grades, placement or discipline, and how can a decision be reviewed by a person?
• What are the classroom rules on AI, and how should my child disclose AI help on homework?
• How will I be told if something goes wrong with a tool my child uses?

For children under 13, federal rules give parents particular rights over data collected online, and the Department of Education has said parents should understand how AI systems function and take part in decisions about adopting them. edCircuit’s AI for Students: A Parent’s Guide by Age covers what parents can do at home.

Governance that lets AI scale

Implementing AI in education is less about choosing tools than about building the discipline that lets tools come and go safely. The frameworks already exist. The NIST AI Risk Management Framework and its Generative AI Profile describe what to govern, ISO/IEC 42001 and COBIT describe how to run it as a management system, SOC 2 reports and contracts bring vendors inside it, and the EU AI Act shows which education uses regulators consider high-risk. The work that remains is local and repeatable: list every use, classify it, review the risky ones before they reach students, write the rules into contracts and systems, train people for their roles, measure learning, and report on a schedule. Institutions that do this will not avoid every problem, but they will see problems early, fix them on the record, and be able to show students, families and their boards why they can be trusted with AI.

Related reading

• AI in Education: A Guide for Schools and Colleges
• Why Every School District Needs an AI Operational Handbook
• AI and Governance in School Districts
• AI Procurement for Schools: 10 Questions to Ask
• How to Implement AI in the K–12 Classroom

Subscribe to edCircuit to stay up to date on all of our shows, podcasts, news, and thought leadership articles.