Governance: name who owns the decision, not just the vendor

A scope of work usually names who builds the system. It rarely names who owns the decisions the system will make or support, who approves a change to its behavior once it is live, and who is accountable when it is wrong.

The U.S. Government Accountability Office's accountability framework for AI treats governance as the first of four load-bearing principles, ahead of data and performance, precisely because the rest of the project inherits whatever governance structure gets set at the start. If nobody signs up to own the decision boundary before the contract is signed, someone will improvise that ownership after launch, under worse conditions.

  • Name a single accountable owner for the decision the workflow supports, not just a project sponsor.
  • Write down who can approve a change to what the system is allowed to do.
  • Define escalation before the first exception happens, not after.

Data: put access and quality requirements in the scope, not the backlog

An AI workflow is limited by what it can reach. If the scope of work does not list every source system, its owner, its access method, and how current the data needs to be, that discovery happens during the build instead of before it, usually as a delay.

The GAO framework's data principle asks entities to assess the quality, reliability, and representativeness of the data before relying on it for a decision. That assessment is cheap on paper and expensive to skip: a missing access grant or a stale data feed discovered mid-build is a schedule problem, but the same gap discovered after go-live is an operational one.

Performance: define what 'done' means before the build starts

A demo that handles the happy path is not the same deliverable as a workflow that handles the volume, edge cases, and exception rate of the real operation. Scopes that describe acceptance as 'the system works' leave that gap for the end of the project, where it is hardest to negotiate.

Performance, in the GAO framework, means results consistent with the program's actual objectives, not results that merely look competent in a walkthrough. Translate that into the contract: specify the test cases, the volume, and the measurable outcome (cycle time, error rate, exception rate) that acceptance depends on, and agree on it before development starts.

Capture what you learn, or the next phase repeats the mistake

A 2026 GAO review of federal AI acquisitions found that agencies were not systematically documenting the lessons from their own AI projects, which meant avoidable mistakes were repeated across later procurements instead of being designed out.

The same failure shows up in smaller organizations without a formal audit to catch it: the workaround the team found for a messy data source, the exception case nobody scoped, the change request that took three weeks to approve, all get relearned on the next phase or the next workflow instead of written down once. A short build log, kept during the project and reviewed at the handoff, is enough to stop that.