What is an AI operating model?
An AI operating model is the set of decisions about how a company organises itself when software performs the work: who owns each function, who approves actions, who controls access to systems, and how the work is reviewed. It is the organisational counterpart to the technology.
Companies that skip this step usually get the same outcome. The pilot works, a second function is added, and then nobody is quite sure who approves what, two teams both believe the other is reviewing, and the audit trail is the only record of what actually happened. The model is what prevents that.
Who should own a Digital FTE?
A Digital FTE should be owned by the person who owns the function it works in, and that ownership should be named rather than implied. If the Search Visibility FTE works on the marketing site, the marketing owner manages it. If the Finance FTE reconciles the ledger, the finance lead does.
This matters because the owner has to feel the consequences of the remit they set. An IT-owned Digital FTE tends to get technically excellent access configuration and vague targets, because the people configuring it do not live with the output. A function-owned one gets sharp targets and, usually, a request for help with permissions — which is the right way round.
Who owns access and permissions?
Access belongs with IT and security even though the work belongs with the function. They decide which systems a Digital FTE may reach, with what scope, and how that is revoked. The split is deliberate: the function owner cannot quietly widen access to make a target easier, and the security team cannot quietly narrow it and break the work without a conversation.
The practical implementation is a short access record per Digital FTE: which systems, which scopes, who approved the grant, and when it is reviewed. On ftes.ai, connections are granted per organization and per property and can be revoked at any time, which makes that record simple to keep honest.
How should approvals be routed?
Approval authority should follow accountability for the outcome rather than availability. The temptation is to route approvals to whoever can clear the queue fastest, which produces speed at the cost of the control being real.
A workable routing rule has three lines. Operational output goes to the function owner. Spend goes to the budget holder, above a threshold the business sets. Anything affecting an individual goes to someone with the authority to make that call. Write the three lines down, because the ambiguity is what causes both delays and unreviewed actions.
- Operational output: function owner
- Spend above a set threshold: budget holder
- Decisions affecting an individual: an authorised human, always
- Novel or first-of-its-kind actions: function owner, regardless of autonomy level
What rhythm should reviews follow?
Reviews should run on a fixed rhythm rather than continuously, because continuous watching is how a manager ends up operating a tool instead of managing a worker. A daily pass over the approvals queue and the morning brief, plus a weekly look at targets and exceptions, is enough for most functions.
The rhythm is also what makes the arrangement sustainable at scale. One manager can hold a daily queue pass for several Digital FTEs; no manager can watch several systems in real time. If a function requires constant supervision, that is a signal that the remit or the guardrails are wrong.
How do you scale from one function to several?
Scale by writing the model down after the first function works, then reusing it rather than re-deciding it. The first deployment is where you discover who should approve what, how long reviews actually take, and which exceptions recur. That knowledge is worth more than the deployment itself.
A one-page record per Digital FTE is usually enough: owner, remit, targets, approval routing, access scope, autonomy level, and review rhythm. When the second and third roles arrive, the question stops being how do we run this and becomes who owns it, which is a much faster conversation.
What does the operating model cost to run each month?
Running the operating model costs a manager about five minutes a day and thirty a month per Digital FTE, plus the approval minutes that fall as autonomy is earned. The daily five minutes is the morning brief: what is waiting, what happened, what was detected, what was spent. The monthly thirty is the review: the FTE's own report against targets, the send-back reasons grouped by category, usage and cost per outcome, and three decisions about targets, remit, and autonomy.
The money side is the plan block, metered in tokens and shared by every FTE, with per-FTE budgets and a hard stop. The model's design keeps both sides bounded: management time falls as classes are promoted, and spend cannot exceed the wallet. An organization adopting the model should record those two costs from the first month, because they are the denominator in every later comparison, and because a model whose management time does not fall over a quarter is telling the manager that the remit is too wide or the ladder is being climbed too slowly.