A named-vendor policy is the artifact everyone has been missing
Most organizations talking about AI governance are still trading principles. Katy ISD, a large district in the Houston area, published something more useful on July 24, 2026: a framework that names the platforms it approves and the tools it restricts, effective for the 2026-27 school year. Amira Learning and Writable are approved. Microsoft Copilot and Google Gemini are restricted on school devices. That specificity is rare, and it is exactly what turns a policy from an aspiration into an operational control that a device-management team can actually enforce on a managed fleet.
The reason this lands now is timing. Generative AI is already in students' hands, and every large institution running a controlled-device environment faces the same question Katy did: which tools are allowed, for whom, and under what supervision. Sanee Bell, Assistant Superintendent of Teaching and Learning at Katy ISD, framed the pressure plainly: "This is the current emerging technology of our time. So it's here, it's in our students hands, they're using it, it's changing how people work." A district publishing its actual allow-and-restrict list gives every other CIO a concrete artifact to benchmark against.
Scaffolding access by grade band mirrors how enterprises should scope by role
The framework tiers access by grade rather than granting a blanket policy. Kindergarten through 6th grade is limited to district-approved platforms, with generative AI tools prohibited outright. Seventh grade opens up to district-approved AI tools under teacher supervision, while non-approved generative tools stay blocked on school devices. Eighth through twelfth grade permits generative AI for specific educational purposes, gated behind teacher authorization and proper citation. Access expands with maturity and oversight, and each band has a clearly defined boundary that the device fleet can enforce.
Swap grade band for job role and this is the access model enterprises keep failing to build. Too many AI rollouts are binary: the tool is either enabled organization-wide or banned. Katy's approach shows a middle path where entry-level users get narrow approved tooling, more trusted users get supervised access, and senior users get generative capability under authorization and attribution requirements. The lesson for a CIO is that a graduated permission model, scoped to who is using the tool and for what, is more defensible and more useful than a single on-off switch applied to the whole population.
Restricting Copilot and Gemini by name is a real vendor decision
Restricting Microsoft Copilot and Google Gemini is a notable call, because both ship deeply inside the productivity suites that districts and enterprises already run. Restricting them on managed devices means the district is willing to accept friction with its incumbent platform vendors rather than let default-on generative features flow to every user. That is the hard part of vendor governance: the AI you most need to control is often bundled into software you already bought, and turning it off requires deliberate configuration rather than simply declining to purchase something new.
This is the build-versus-buy tension in its current form. Approved tools like Amira Learning and Writable, the latter from HMH, are purpose-built for the education context and easier to bound. General-purpose assistants from the hyperscalers are powerful but harder to scope to a specific, supervised use case. Any leader evaluating AI vendors should read Katy's split as a signal: narrow, domain-specific tools with clear data and usage boundaries are easier to approve than horizontal assistants whose capabilities and data flows are broad by design. The approval bar should reflect that difference.
Literacy and a parent committee treat governance as a program
The technical controls are only half of it. Katy ISD is launching an AI literacy course when teachers return from summer break, and it has invited parents onto a district AI advisory committee. The framework and the approved-tool list are posted publicly on the district website. Together these move the effort past a filter list and into an ongoing program with training, transparency, and a stakeholder feedback loop. The people expected to work inside the guardrails are being taught what the guardrails are and why they exist, which is what makes a policy stick.
Enterprises consistently underinvest here. They publish an acceptable-use policy, configure a few blocks, and call the AI governance question closed. Katy's model suggests a fuller obligation: pair the restrictions with literacy so users understand the reasoning, and stand up a channel for the affected community to weigh in. For a CIO, that means budgeting for enablement and communication alongside tooling, and accepting that an AI policy is a living program that needs an owner, a training track, and a review cadence rather than a one-time configuration change.
Citation and authorization requirements are the audit trail
For the oldest students, generative AI is permitted only for specific educational purposes, with teacher authorization and proper citation required. Those two conditions are the accountability layer. Authorization means a human signs off on the use case before the tool is applied, and citation means the AI's contribution is disclosed and traceable after the fact. This is the same before-and-after control structure that regulated enterprises need when they put AI into a real workflow: approval at the front, attribution at the back, and a record that connects the two.
The parallel to enterprise practice is direct. Regulated firms stalling their AI agents in pilot usually lack exactly this: a clear authorization gate and a durable record of what the model did and where its output went. Katy has encoded both into classroom rules that a teacher can apply without a compliance team. A CIO should take the pattern seriously, because scoped authorization plus mandatory disclosure of AI involvement is far cheaper to implement early than to retrofit after a tool is already embedded across the organization and nobody can reconstruct how output was produced.
What this means for your AI vendor roadmap
Read Katy ISD as a case study in owning the vendor-approval decision instead of deferring it. The district did the unglamorous work: it decided which tools are in, which are out, who can use what, and what has to be true before and after each use. That is precisely the work a CIO or CISO must do before generative AI vendors get approved across a controlled fleet. The output is a short, enforceable list backed by grade-scoped, or role-scoped, permissions and a supervision model, published where the affected users can see it.
The move for your roadmap is to produce your own version of this artifact. Inventory the AI already bundled into your incumbent platforms, decide explicitly whether to allow or restrict each on managed devices, and define graduated access by role rather than flipping one switch for everyone. Pair it with authorization and attribution requirements for higher-risk use, fund the literacy program that makes it real, and give it an owner. Katy did this for a school district under public scrutiny. The pattern transfers cleanly to any enterprise that has stopped pretending generative AI is optional.
