Another AI licence is not an operating model. If teams cannot explain which decision the tool supports, which information it may use, which workflow state it can change, who owns the consequence and how performance is reviewed, purchasing adds capability without adding control.
The direct answer is to design the accountable relationships between decisions, information, workflows, software, authority and feedback before tools define those relationships accidentally.
The fragmented condition
Fragmentation is visible when different teams buy overlapping tools, copy the same business information into separate systems, run pilots without a common owner, or rely on people to reconcile outputs after the fact. The problem is not simply duplicate spend. Each local implementation creates assumptions about data, permissions, handoffs and success. Those assumptions become expensive to unwind once work depends on them.
NIST's AI Risk Management Framework organises risk work around Govern, Map, Measure and Manage, with governance crossing the other functions. ISO describes an AI management system as interrelated elements for policies, objectives and processes around responsible AI development or use. Those are external reference points. The five-layer architecture below is netlinkE's operating recommendation for turning that governance intent into a purchasing and implementation sequence.
The five-layer AI operating architecture
| Layer | Decision it must settle | Evidence to produce |
|---|---|---|
| 1. Decision and authority | What business decision is supported, who owns it, and what may the system do? | Named owner, authority boundary, approval and escalation rules |
| 2. Information and state | What information is permitted, sufficiently reliable and current, and what state is the work in? | Source register, provenance, state definitions, retention rules |
| 3. Workflow and integration | Where does work start, change hands, encounter exceptions and complete? | Workflow map, system-of-record changes, exception and recovery paths |
| 4. AI and software capability | Which capability is proportionate to the bounded task? | Tool evaluation, model constraints, integration contract, test results |
| 5. Governance and measurement | How will outcomes, risk, drift, incidents and value be reviewed? | Outcome measures, logs, review cadence, change record and stop criteria |
The layers are ordered for design, not isolated in operation. Measurement may reveal an information defect; an exception may require a narrower authority boundary; a workflow change may make the original model unnecessary. The architecture should make those feedback relationships visible.
Start with a decision, not a department
“Use AI in customer service” is too broad. A bounded starting decision might be: classify a new enquiry, identify the responsible service team and prepare a response for human review. That statement exposes an owner, required information, the handoff, the permitted action and the point of review.
Now ask what failure means. A low-confidence classification might be reversible. Sending an inaccurate contractual commitment is not. Consequence, not novelty, should determine how much evidence, oversight and recovery the system needs.
Build the information and workflow contract
Inventory the sources the task actually needs. For each source, record ownership, permitted use, update behaviour and the state it represents. Then map the workflow from trigger to outcome, including exceptions. A tool should not be asked to infer whether a record is final, whether an approval exists or which system is authoritative when the organisation has never settled those questions.
This is also where integrations become architectural rather than convenient. Define which system owns each state change, what identifier connects records and what happens when an update partially fails. A successful model response is not a successful workflow if the business record is wrong.
Select capability only after the boundary exists
With the first three layers defined, tool evaluation becomes specific. The organisation can test whether a product supports the required permissions, provenance, review state, portability, observability and recovery. Features that do not serve the bounded decision become optional rather than persuasive.
Do not buy broad autonomous action, another disconnected knowledge store, or an analytics layer before the underlying state and outcome are defined. Do not consolidate tools merely to reduce the vendor count; consolidate around an operating contract.
Implement one accountable slice
Choose one consequential but bounded workflow slice. Establish the baseline, run representative cases and exceptions, keep a human review path, and record what changes. Expansion should follow evidence that the operating relationship works: the decision is better or faster, the information remains trustworthy, exceptions are recoverable and ownership is real.
The next purchase decision is then straightforward: does the proposed capability strengthen a defined layer, remove a measured constraint or duplicate something the operating system already provides? If the answer cannot be shown, the organisation is not yet choosing infrastructure. It is accumulating tools.
Sources and scope
This article uses NIST AI RMF and Playbook material and ISO's public ISO/IEC 42001 overview as external governance context. The five-layer architecture, purchasing sequence and decision tests are original netlinkE analysis and recommendations. They do not assert certification or legal compliance.
