If you run agents in production today: can you name, per agent, the process steps it may trigger without asking? That question has an owner and a threshold, or it has no answer.
#AgenticAI #EnterpriseAI #CISO #AIGovernance
11/11
1
7
Where that is unresolved, the organisation escalates instead of acting, and escalation during an incident consumes exactly the hours that determine its size.
A decision matrix with named roles costs nothing.
It fits in one workshop.
10/11
1
4
No licence covers that, and no procurement will produce it.
Which brings me to the cheapest item on the list and the one most often missing.
Who decides to halt an agent at 3am on a Sunday, and at what threshold?
9/11
1
2
A well-kept architecture repository lets you argue about criticality with evidence instead of instinct, and that is a real gain.
What it does not produce is the decision itself: which step an agent may change, at which threshold, with whose countersignature.
8/11
1
2
The common answer is that no new tooling is needed because process modelling and enterprise architecture already exist in house.
That is half right.
7/11
1
1
A system map records what is connected to what. It does not record what may be changed by whom under which condition. That is a different document, and most organisations do not have it.
6/11
1
1
2. Which thresholds apply? Value, volume, frequency, deviation from norm. The threshold is what separates an agent acting from an agent asking.
3. Where does a human countersign? As a defined step with a named role and a response time, not as a formality.
4/11
1
4
Four questions govern that, and none of them is answerable on a system map:
1. Which process steps may the agent alter? Not which systems it can reach. Which steps it may change the state of.
3/11
1
10
The larger one: the agent does exactly what it was built to do, in a situation nobody anticipated at design time. No anomaly. No injection signature. No alert. A correct-looking transaction with a wrong business outcome.
2/11
1
13
Hardening your model does not answer the question that decides your agent risk.
Model hardening asks whether the agent can be tricked into doing something it should not. Useful, real, and the smaller of two exposures.
1/11
1
29
If that page cannot be filled in, the gap is real and it is not a procurement problem.
Anyone on the buying side: does your framework name an outcome owner per process, or only rates per profile?
#Sourcing #Procurement #ServiceDelivery #COO #VendorManagement
9/9
5
The exercise that changes it, and it fits on one page: for each critical process, write down which supplier owns the result, which metric shows it is going wrong, and who decides in a conflict.
8/9
1
2
None of this argues against frameworks or against multi-supplier setups. It argues that the delivery side has to bring something to the renewal other than a demand for lower rates.
7/9
1
3
Who decides when two suppliers disagree. In practice, the client project manager, in the moment, without a mandate. That is not a governance model, it is an accident that keeps working until it does not.
6/9
1
3
Which metric would have surfaced the problem early. Suppliers are measured on utilisation and delivery against plan. Neither catches architectural drift, and drift is what makes year two expensive.
5/9
1
2
What "done" means, in writing, signed. Definitions of done live in slide decks and get reinterpreted at every acceptance meeting.
4/9
1
1
Who owns the result when three suppliers touch one process. Each contract defines a scope of activity. None defines an outcome, so the space between the scopes belongs to the client by default.
3/9
1
7
What a framework reliably settles: rates per profile, availability, notice periods, liability caps, and what happens if an invoice is disputed. Genuinely necessary, and negotiated hard.
What it typically leaves open:
2/9
1
11








