Enterprise AI Standard — Jim Costigan

This is the sanitized, generalized form of a governance model built and run inside the CIO organization of an enterprise security company. Nothing here is specific to that company, and no proprietary material is included. It is published as a reference because the problem it solves is now common and the answer is mostly not written down.

Requirement language follows the usual convention: MUST is a gate, and work does not proceed without it. SHOULD is the default, and a departure needs a named owner who accepted it. MAY is permitted.

§ 0

Scope and the problem this addresses

What the standard governs, and what it deliberately leaves alone.

An enterprise six to twelve months into “we need an AI strategy” usually has the same four symptoms: tools nobody approved, no way to tell a board what is in production or what it costs, security asking questions nobody can answer, and pilots that never reach production because no one defined what done means.

None of those are strategy problems. They are the absence of an operating model. A strategy deck does not fix them; a classification, an intake path, a release gate and a measurement model do, because together they decide what gets built, who answers for it, and when it is allowed to run.

This standard governs any solution that calls a language or generative model, in any environment, including solutions assembled from vendor tools rather than written in-house. It does not govern model training or fine-tuning, which belong to a separate engineering standard, and it does not replace an existing data-classification policy — it consumes one. Where an enterprise already has data classification, the trust tier in §1 is derived from it rather than invented alongside it.

§ 1

Trust classification

Four tiers. The tier sets the controls, the review path and the approval authority.

Every solution carries exactly one tier, assigned at intake and reassessed when its data, autonomy or audience changes. The tier is not a judgment about how important the work is. It is a statement about what happens if the system is wrong, and it is the single input that determines everything downstream.

Two rules make the classification hold. A solution inherits the highest tier of any data it can reach, not the tier of the data it intends to use. And autonomy escalates a tier on its own: a system that takes an action is held to a higher standard than one that drafts an output a person then sends.

Tier	Applies when	Required controls	Approval
T1Open	No company or customer data leaves the session. Public or general-knowledge inputs only. Output is read by one person.	Approved tool list Acceptable-use acknowledgement No credential access	Self-service
T2Internal	Internal non-regulated data. Output informs internal work or is shared within a team.	Named owner of record Company-owned environment Scoped, rotated credentials Prompt and output retention set deliberately	Function lead
T3Restricted	Regulated, customer, personal or contractually controlled data. Or output that reaches a customer.	Everything in T2, plus: Security and privacy review before build Full audit trail of inputs, outputs and actors Documented evaluation set with a pass threshold Named human accountable for each release	Security + data owner
T4Critical	The system acts rather than advises: it writes to a system of record, moves money, grants access, or produces a determination about a person.	Everything in T3, plus: Executive sponsor of record Defined blast radius and a tested kill path Human confirmation on irreversible actions Scheduled re-evaluation, not one-time sign-off	Executive + security sign-off

The tiers are deliberately coarse. A six-tier model looks more rigorous and gets argued about at intake instead of used; four tiers can be assigned in a five-minute conversation, which is the only property that matters in practice.

§ 2

Intake, credentials and keys

One queue, one classification conversation, one path to a key.

Shadow AI is not a discipline problem. It is what people do when the approved path is slower than the unapproved one. The intake path therefore has a service commitment attached to it, and the commitment is the control: if classification and a scoped key take two days, people use the path; if they take six weeks, no policy will hold.

All AI work MUST enter through a single intake queue, including vendor tools and departmental experiments. Parallel departmental pipelines MUST be consolidated into it — one prioritized queue is the point, not a form.
Intake MUST record, at minimum: the business outcome in one sentence, the data the solution can reach, the named owner, the requested tier, and whether the system advises or acts.
API keys and model credentials MUST be issued to a named owner, scoped to a single solution, and rotated on a schedule. Shared or team-pooled keys MUST NOT be issued, because they make the audit trail in §1 unenforceable.
Key issuance MUST be tied to tier assignment. A credential is the artifact that proves classification happened, which is what makes the queue self-enforcing.
Spend SHOULD be attributable to the solution and the owner from the first key, not reconstructed later from an aggregate invoice.
Intake SHOULD publish a standing turnaround commitment and report against it. The queue competes with the unapproved path on convenience or it loses.

§ 3

Proof of function

The release gate. This is the clause that moves pilots into production.

Most AI programs do not fail at the idea or the model. They fail at the handoff, because “it works” was demonstrated on a laptop, against a sample, by the person who built it. Proof of function makes that demonstration a defined artifact rather than a conversation.

A story does not close until all five are true

The solution runs in a named, company-owned environment — not a personal account, not a vendor trial, not a developer machine.
It runs against real inputs in that environment, in the shape and volume it will actually see.
Its output is checked against a written evaluation set with a stated pass threshold, defined before the run. For T3 and T4 the evaluation set and threshold are reviewed by someone other than the builder.
A named person other than the builder has operated it and confirmed the result.
Someone other than the builder can run it again from written instructions, without asking the builder a question.

Clause 5 is the one that gets argued about and the one that does the work. A solution only one person can operate is a prototype regardless of how well it performs, and treating it as production is how an organization acquires a dependency it cannot staff.

Quality rubrics are tier-scoped and defined with the domain experts who own the work, not by the delivery team alone. The practitioner who will live with the output decides what good means; the standard only requires that the decision be written down before the system is built and measured after.

§ 4

Accountability across the lifecycle

Who is responsible, and who answers for it. These are different people.

The failure mode this clause exists to prevent is the one where an AI solution is running in production and no one can say whose it is. Accountability is assigned at intake and travels with the solution, including after the team that built it has moved on.

Lifecycle stage	Solution owner	Domain expert	Security & privacy	Program	Executive sponsor
Intake & classification	R	C	A	C	I
Rubric & evaluation set	C	R	C	A	I
Build & prototype	R	C	I	A	—
Proof of function	R	A	C	C	I
Release (T3 / T4)	C	C	R	C	A
Operation & monitoring	R	C	C	I	A
Re-evaluation & retirement	C	C	R	A	I

R responsible · A accountable · C consulted · I informed. Exactly one accountable party per stage; the moment there are two, there are none.

§ 5

Capacity-gated sequencing

Why a roadmap sequences against hardware rather than against enthusiasm.

AI delivery plans fail on capacity more often than on scope. Inference needs GPUs, GPUs have lead times, and a roadmap that commits to a date the hardware cannot support produces a program that is late from the day it is published.

Work MUST be sequenced against committed capacity — environment, GPU and quota availability — and not against the order requests arrived in.
Each roadmap item MUST name the capacity it depends on. An item whose dependency is unfunded is a candidate, not a commitment, and MUST be shown as one.
Build-versus-buy for inference SHOULD be decided on a written unit-cost model comparing per-token commercial pricing against the loaded cost of owned serving at the expected volume. Both curves SHOULD be modelled, because they cross, and where they cross is the decision. Own, rent, cache works through one such model.
A hybrid routing posture MAY be adopted, sending traffic to commercial or owned inference by workload class. Where it is, the routing policy MUST be explicit about which tiers of data are permitted to leave the enterprise boundary.

§ 6

Measuring value

What counts as value, how it is attributed, and what must be instrumented first.

Most organizations cannot answer “what is AI worth to us” because nobody defined what counts as value or who it is attributed to. The deliverable is not a number. It is the instrument that produces the number — and the instrument has to exist before the quarter it is asked about, because measurement cannot be applied retroactively to work that was never instrumented.

Four questions have to be answered in order. Answering them out of order is how programs end up reporting activity as though it were value.

01 · Definition

What counts as value here?

Hours returned, cost avoided, cycle time, error rate, or a capability the function did not previously have. Named per initiative before build, not selected afterward from whatever moved.

02 · Attribution

Who gets credit, and against what baseline?

The owning function, with a pre-recorded baseline. Without a baseline captured before the change, there is no defensible claim later.

03 · Instrumentation

What has to be measured to report it?

The specific events, logs and counters required — identified at intake and built into the solution, because retrofitting telemetry costs more than including it.

04 · Reporting

What does an executive see, and how often?

One cadence, one surface, generated from live delivery data rather than assembled by hand. A report that takes a person a day to build is reported late or not at all.

Efficiency and effectiveness are reported separately. Efficiency — hours saved, cost reduced — is easier to measure and consistently understates the result. Effectiveness is the work that was not previously possible at all, and it is usually the reason the program was funded. A program that reports only efficiency will be evaluated as a cost-reduction exercise and funded like one.

§ 7

Adopting this

The order that works, and the order that does not.

The sequence matters more than the content. Organizations that start with the policy document produce a policy nobody routes work through. Organizations that start with the intake queue acquire the policy as a by-product, because every intake conversation forces a classification decision and the tiers write themselves from the first twenty.

Stand up the intake queue first, even as a form and a weekly triage. It is the only clause that changes behaviour on day one.
Classify what is already running before governing anything new. The inventory is usually the finding that funds the rest of the work.
Apply proof of function to the next release, not retroactively to everything. One gated release establishes the standard more effectively than a memo announcing it.
Define value and baselines for the next initiative before it is built, while the baseline is still capturable.
Write the standard last, from decisions already made. A standard documenting observed practice gets adopted; a standard proposing it gets negotiated.

About this document

James Costigan builds enterprise AI programs from a standing start — governance, intake, delivery standards and executive reporting — so the work becomes fundable, auditable and shippable. This standard, the trust classification and the measurement model in §6 were built and run inside the CIO organization of an enterprise security company across a six-month build engagement, and handed over as the operating model the program now runs on.

Prior to that: product management on a hosting platform serving 51 million domains, and a 30-person R&D development team built and funded at a global oilfield services company, reporting to the CIO and CTO across three regions.

This document is published as a reference and may be used, adapted and cited freely with attribution. It is deliberately generic: anything specific to a particular company has been removed, and nothing proprietary is included.

jim@costigan.com

Location

Sacramento, CA

Engagements

Start a conversation