Transparency in development

When customers audit Bizzi or evaluate us against a competing AI vendor, they need three things on paper. What data the model was trained on. What version is in production. How it performs against its target. We maintain three standard documents to give them the answer without a discovery call.

Context

The reason most AI procurement reviews stall is not lack of capability. It is the inability to describe the model in writing. Auditors do not trust what they do not read. We treat documentation as a deliverable which ships with the model, not a courtesy which follows when there is time.

Principle: The documentation rule

Every production AI model has a current Model Card, a current Data Card for its training data, and a Design Doc preserved in the document management system. No model goes to production without all three signed off.

Model Card

Available to contracted customers, the Model Card carries:

• Metadata. Model name, version, release date, Business Owner, Tech Lead, base model (if fine-tuned from an open-source or commercial foundation), and license attestation.
• Use case. Description, applicable scope (tenant size, industry, region), and an explicit list of out-of-scope use cases.
• Training summary. Categories of training data (anonymized, never specific records), augmentation techniques, and validation methodology.
• Performance. Current KPIs against target. Accuracy, hallucination rate, latency. Broken down per cohort (SME, mid-market, enterprise, banking) and compared to the previous version.
• Limitations. Known failure modes (for example, OCR accuracy degrades on invoices rotated more than 15°), the edge cases which need human attention, and the date of last evaluation.
• Risk classification. Low, Medium, or High per the 6-step gate.

Data Card

Each training dataset has a Data Card covering:

• Source. Where the data came from. Anonymized customer data, synthetic, or public corpus.
• Composition. Size and distribution by category.
• Collection method. Manually labelled, automatically labelled, or scraped.
• Quality measures. Percentage of samples reviewed by senior QA, inter-rater agreement scores.
• Bias considerations. Skew we are aware of and what we did about it.
• Legal basis. Consent, contract, or legitimate interest under Decree 13.
• Retention policy. How long the dataset is kept and when it is purged.

Design Doc

Before any large AI feature is built, the squad writes a Design Doc which names:

• Problem statement. Why we are building this.
• Goals and non-goals. What success looks like and what is out of scope.
• Alternatives considered. The two or three approaches we evaluated before choosing this one.
• Architecture. A diagram and the key technical decisions.
• Risks. Technical, legal, and security risks, each with a mitigation.
• Success metrics. The KPIs which determine whether the feature stays in production.
• Rollout plan. Phases, the dial-up schedule, and the kill criteria which revert it.

Design Docs are internal. They are shared under NDA with contracted customers conducting due diligence.

Versioning and storage

Model Cards and Data Cards are versioned with every release and stored in the document management system with immutable history. Customers subscribe to notifications when the cards change. The version pinned to any given decision is retrieved from the audit trail.

Standards mapping

Standards Mapping

ISO/IEC 42001. A.6.2 (Documented information), A.7.1 (Operational planning and control). NIST AI RMF. GOVERN-1.4 (Documentation is comprehensive, accurate, and current). EU AI Act. Art. 11 (Technical documentation).