By role
Five people, one problem, five entirely different Mondays.
A CISO is being asked what the company's AI exposure is. A platform team is being asked to make agents work without becoming the department of no. They are looking at the same artifacts and they do not agree about what to do, because they are not accountable for the same failure.
how these pages are written
Each page opens with what that role cannot currently answer when asked — because a page that cannot name the specific question landing on somebody's desk was not written for them, it was written for a segment.
The checklist on each page works with nothing purchased. Where we fit appears once, at the end, in that role's priority order.
The disagreement is structural, not political
Security wants artifacts reviewed before they run. Platform wants engineers unblocked. Compliance wants evidence that survives an auditor. Engineering leadership wants the productivity gain that justified the spend. Each of those is correct from where the person is standing, and the usual outcome is that whoever escalates loudest sets policy for a quarter until the next incident resets it.
What makes the argument resolvable is noticing that all four positions are downstream of the same missing fact: nobody knows what is actually installed. Security cannot risk-rank what it cannot enumerate. Platform cannot approve a fast path without knowing what the slow path is protecting against. Compliance cannot evidence a control that produces no record. Leadership cannot attribute a productivity change to a configuration nobody tracked.
That is why these pages converge on inventory before they converge on anything else, and why the recommendation is the same across five very different job descriptions even though the reasoning to reach it is completely different in each case.
5 / 5 roles
Nothing matches that. Try a different term or clear the filter.
- Security
CISO
You own the answer to 'are we exposed', and you own it without having chosen the tools that created the exposure. AI adoption in most organisations happened bottom-up and fast: engineers installed coding agents, teams bought seats on cards, and connectors were pointed at internal systems by people who had the credentials to do it. You are accountable for a footprint you did not design and cannot fully see, and the honest first move is inventory rather than policy.
Chief Information Security Officer · VP of Security · Head of Information Security
- Engineering
Platform engineering
You own the paved road, which means you own whether the safe path is also the fast path. Security will hand you controls and engineers will hand you complaints, and both are legitimate. The specific failure to avoid is building a governance process whose latency exceeds the cost of going around it — at that point you have not added a control, you have added an incentive, and you will lose visibility of exactly the usage you most needed to see.
Developer experience · Developer productivity · Internal tooling · DevEx lead
- Security
Security engineering
You own the controls, which means you own the honest ranking of them. There is enormous pressure to deploy a detector or a guard prompt and declare the problem addressed, because that is legible to everyone above you. The engineering reality is that injection is a property of instruction-following models rather than a bug, so your leverage is almost entirely in authorisation, egress and reversibility — and your hardest job is defending that ordering against solutions that demo better.
Application security · Product security · Security architect · AppSec engineer
- Governance
Compliance and audit
You own the difference between what the organisation asserts and what it can demonstrate. That is a narrower and more useful job than owning the policy itself, and in AI it is unusually exposed: most AI policies were written quickly, describe controls nobody instrumented, and have not been tested against a request for evidence. Your value is finding those before an auditor or an enterprise customer does, and converting them into either instrumentation or an honest register entry.
GRC lead · Risk and compliance · Internal audit · Data protection officer
- Engineering
Engineering leadership
You own two claims that currently rest on the same thin evidence: that the spend is justified, and that the tools are not creating risk. The uncomfortable part is that the obvious measurements are traps — per-developer token spend produces gaming, lines-of-code metrics reward the wrong output, and satisfaction surveys measure enthusiasm rather than throughput. Getting this right is mostly about picking measurements that survive contact with the people being measured.
VP of Engineering · Director of Engineering · CTO · Head of Engineering
Frequently asked
- Who should own AI supply-chain security?
- Whoever already owns software supply-chain security, in almost every organisation that has answered this well. The failure mode is creating a new AI governance function that owns policy without owning any enforcement path — it produces documents, not controls. What is genuinely new is the artifact classes, not the discipline.
- Our security and platform teams disagree about agent tooling. Who is right?
- Both, about different failures. Security is accountable for the incident that has not happened yet; platform is accountable for the engineers who are blocked today. The disagreement dissolves when there is a fast approved path — a reviewed, pinned set of artifacts engineers can adopt in minutes — because then the compliant route and the quick route are the same route.
- We are too small for role-specific programmes. Does this apply?
- The functions apply even when they are the same person wearing four hats, and arguably more so — one person holding all four accountabilities feels the contradictions directly rather than escalating them. Start with whichever page describes the question you are currently being asked.
- Why do all five pages recommend inventory first?
- Because each function's specific obligation turns out to be unachievable without it, for entirely different reasons. That is not a template — it is what happens when you follow five separate lines of reasoning and they land in the same place, which is usually a sign the place is right.
Where to go from here
One inventory, five different questions answered from it
Vincosha Registry is the single source for what every AI surface loads, Vincosha Assay vets it before it lands, and Vincosha Ledger attributes sessions and spend to the artifact versions that were active. Security, platform, compliance and leadership then argue from the same list instead of from four different guesses.