Accountability

III

Pillar III of V

Ethics, Transparency & Interpretability

Bizzi AI is not a black box. Every decision has a source, every feature has an owner, and every output is explained to the person it affects.

An AI system is not accountable. An organization is. Every AI feature at Bizzi ties to a named individual who is answerable for it. Not “the team”. Not “the department”. A person whose name is in the service catalogue.

Context

Accountability gaps are the most common failure mode in AI governance reviews. When a model misclassifies an invoice, flags a legitimate payment, or hallucinates a vendor name, the question “who owns this?” needs an answer ready before the incident, not after. Without a named owner, escalation stalls. Fixes drift across squads. Customers lose trust in the audit trail.

Principle: The accountability rule

Every AI feature in production at Bizzi names a Business Owner, a Tech Lead, and a DPIA Owner. The names live in the service catalogue. If one of them leaves the role, the transition is recorded in CHANGELOG within two weeks. There is no concept of an unowned feature.

How we implement

• Business Owner per feature. When an AI feature enters sprint planning, the owner is registered in the service catalogue. The owner is usually the squad’s Product Owner, not an engineer. Engineering owns how. The Business Owner owns whether the feature stays alive.
• Decision rights are explicit. The Business Owner decides feature scope, release timing within the 6-step gate, KPI targets, and customer communication. The Business Owner does not bypass the 6-step gate, override CoE standards, or skip a DPIA.
• Non-transferable in practice. Accountability does not move silently. When the owner rotates roles, the transition is formalized in CHANGELOG with the new owner accepting in writing. Temporary ownership stays under two weeks.
• Audit trail closes the loop. Each AI decision carries model version, dataset, prompt, and HITL approver when applicable. Tracing responsibility back from any incident is a query, not an investigation.
• Escalation has one path. Incidents route through the Business Owner first, then the CoE Lead, then the AI Governance Board for SEV-1 or SEV-2 severity.

What the Model Card publishes

Each production model has a Model Card available to contracted customers. The card declares ownership, scope, training data categories, current performance against target, known failure modes, the 6-step risk classification, and the last evaluation date. Customers read the card before procurement. They re-read it whenever a model version changes.

Standards mapping

Standards Mapping

ISO/IEC 42001. A.6.2 (Roles, responsibilities, and authorities). NIST AI RMF. GOVERN-2.1 (Roles and responsibilities documented), MANAGE-4 (Risk treatments documented and tracked). EU AI Act. Art. 13 (Transparency and provision of information).

Example. A feature with named ownership

The auto-categorize business travel expenses feature ships with a Business Owner (the Product Owner of the owning squad), a Tech Lead (the Senior Engineer on the OCR pipeline), a DPIA Owner (the DPO), a risk classification of Medium (errors are inconvenient but reversible), and a mandatory HITL trigger for expenses over 5 million VND or two standard deviations above tenant baseline. When the squad receives an incident, the path is unambiguous from the first ticket.