Why can the AI not be accountable?
The AI cannot be accountable because accountability means answering for a decision and bearing its consequences, and software does neither. When something goes wrong, a regulator, a customer, or a colleague will ask who decided, and the answer has to be a person.
Any governance model for AI employees therefore has to answer one question: for every action, which named person is accountable, and how do we know? The Digital FTE model on ftes.ai answers it with three mechanisms.
How does the approval gate assign accountability?
The approval gate assigns accountability by requiring a named person to approve each action before it happens. A Digital FTE proposes; the manager approves, edits, or sends back; the action happens only after approval. The approver is the accountable party, and their name is in the record.
This holds for every class of action at Level 0 on the autonomy ladder, which is where every Digital FTE starts. Nothing publishes, sends, posts, or spends without a person's approval until that specific class has been promoted.
What happens when autonomy is granted?
When a class of action is promoted on the autonomy ladder, accountability shifts to the person who granted the autonomy, and that grant is logged with their name, the class, and the date. The manager who lets exact-match reconciliations auto-approve is accountable for that decision, and the record shows they made it from an approval history that justified it.
Autonomy can be stepped back at any time by the same route, and that is logged too. Accountability is never diffuse; it is always traceable to a grant or an approval by a named person.
- Level 0: the approver of each action is accountable
- Promoted class: the person who granted autonomy is accountable
- Stepped back: logged, accountability returns to per-action approval
- Never automated: the person who acts is accountable, as before
What is never automated?
A fixed list of decisions is never automated on ftes.ai, at any autonomy level: rejections, offers, and anything affecting a person's employment outcome; refunds, credits, and debt escalation; pricing and contract terms; and anything on the always-escalate list a manager sets for a role.
For these, the Digital FTE prepares and a person decides and acts, so accountability sits exactly where it did before the FTE was hired. This is a design commitment rather than a setting, and any vendor evaluation should ask for the equivalent list.
How does the audit trail support this?
The audit trail records every proposal, approval, send-back, publish, spend, and autonomy change with who, what, and when. When a question is asked later, the answer is a record rather than a reconstruction: this action was approved by this person on this date from this evidence.
That record is what makes the accountability model real rather than nominal. A named manager who approves without a record is accountable in theory; one whose approvals are logged is accountable in a way that can be demonstrated.
What should an organization write down about accountability?
An organization should write down three things, and keep them where the audit trail can be read against them. First, who the named manager of each Digital FTE is, because the manager is the approver of gated actions and the grantor of any autonomy, and a role with no named manager has nobody accountable. Second, the always-escalate list for each role and the platform's never-automated list, so that the actions that must stay human are stated rather than assumed. Third, the rule for promotion and step-back on the autonomy ladder: what length of clean approval record the organization requires before a class is promoted, and the triggers that step it back.
None of this is long. A page per role, reviewed at the monthly review and updated when the manager changes, is enough, and on ftes.ai the first two are visible in the workspace already: the manager in the workforce view, the lists in each remit and in the platform's design. Writing the third down turns the ladder from a manager's habit into an organizational standard, which is what a regulator, an auditor, or a new executive will ask to see.