ZAION: G7 Hiroshima AI Process (HAIP) Transparency Report

Zaion is a provider of conversational AI for customer relations (Voice and Chat AI) for clients in insurance, banking, health, assistance, public services, utilities, transport and telecommunications. We do not train foundation or general-purpose models. We develop proprietary speech and language components and integrate third-party foundation models under contractual and technical controls.

Our thresholds are harm-severity-based rather than capability-based: we assess impact, reversibility and scale in the specific deployment context (consistent with NIST AI RMF), rather than against model capability thresholds, which apply to frontier model developers.
Contexts we assess as unreasonable absent mitigation: (i) a caller unable to reach a human when circumstances require it, including distress or a safeguarding concern; (ii) automated handling producing legal or similarly significant effects on a caller without human review; (iii) deployment without disclosure that the caller is speaking with an automated system; (iv) systematically degraded recognition for an identifiable caller group, producing unequal access to a service.
Graduation of mitigations: conversational scope is the primary control. An intent is admitted to automation only where accuracy and escalation behaviour meet acceptance criteria; where they cannot be met reliably the intent is withdrawn from automated scope. Confidence thresholds trigger escalation, so a recognition or comprehension failure degrades into a human conversation rather than a failed service interaction.
Generative and agentic specificity: generative responses are grounded in client-approved knowledge sources rather than open-ended generation. Also, agentic capabilities are governed by an action allowlist based on client specification and a declared-tools-only policy to block faulty actions.

Bounded agent steps through a recursion limit; an allowlist of permitted actions; execution restricted to declared tools only; capture of tool errors; and loop detection applied to both input and output.
Multi-agent interaction: the gateway agent and its sub-agents interact with the platform orchestrator and with tools. Those interactions are bounded by loop detection across the conversation history, a per-call request cap and per-call and per-conversation token budgets. Every agent step is recorded in the trace returned to the orchestrator, so the deploying organisation can see exactly what was done.

Zaion operates multilingual conversational AI systems using both its own proprietary and third-party models. We frequently evaluate and measure performance for different populations and run gender-stratified evaluation of our speech models against our fairness target, and expert linguists review model and voice quality. We document the limitation openly to tackle them based on our R&D approach. All the evaluations are run by our internal teams, which are both multidisciplinary and multicultural

Incidents are captured automatically rather than waiting to be reported. Every response carries a structured trace recording the error type and description, which provider and model were used, and any warnings, correlated by request identifier with our metrics. Recurrent issues are analysed, a fix and a regression test are added together, and thresholds or configuration are updated. Provider-side incidents such as outages or content-filter events are handled automatically by fallback and circuit breaking before they reach the caller.
At platform level we monitor accuracy, drift and output quality, fairness degradation against threshold, and security signals including adversarial attacks, data poisoning and unusual inference patterns. Model performance - accuracy, fairness, explainability and drift - is reviewed quarterly. Incident logs are analysed monthly. Impact assessment coverage is reported quarterly.
Escalation clocks are defined. An incident or complaint triggers a fresh impact assessment. Where any monitored metric falls below threshold, the owner has specific period to escalate with a remediation plan.

Access depends on legal obligation, contractual commitment and risk level.
For staff: a confidential, explicitly retaliation-free process for raising concerns about AI misuse, unethical outputs, bias, safety, security vulnerabilities or policy breaches. Reports go to a dedicated mailbox, directly to the AI Lead or CISO and all are logged in the AI management incident register. Reporter identity is protected as far as the law allows and retaliation is itself a disciplinary offence. 
For clients: enterprise customers have standing account and support channels with SLA-backed escalation, and in practice the diagnostic trace returned with every request makes reporting a problem straightforward - they can see which model answered, what it did and what went wrong. Product documentation must carry a dedicated route for AI-related questions and an escalation path for failures, unexpected outputs or bias concerns. Customers, partners and suppliers are also served through our Trust Centre.
Public URLs: https://developers.zaion.ai/docs/platform/security/overview
 

• Information-sharing partnerships (with confidentiality agreements as appropriate)
• Reporting to regulatory authorities as relevant

Policy updates to all employees annually or on revision. Risk and incident reports to compliance, executives and regulators where required. System performance reports to leadership and engineering twice a year. Management review outcomes to the executive team annually. Supplier compliance updates twice a year through the Trust Centre. Customer transparency and ethics reports annually through the Trust Centre.
Incident content shared with clients covers what happened, its scope, which data categories were affected and what we did. Personal data breaches go to CNIL within 72 hours and to affected individuals without undue delay where their risk is high. Serious AI incidents go to the competent national authority without undue delay.

Zaion does not run a paid bug bounty or a formal external disclosure programme with safe harbour.
What we do run is an internal confidential, explicitly retaliation-free channel for AI ethics, bias, safety and security concerns, open to every employee and contractor. Also, Zaion maintain an engineering culture of writing findings down - findings reports, risks flagged in service documentation, peer review.

 

• ISO/IEC standards (e.g., ISO/IEC 27001, ISO/IEC 42001, ISO/IEC 23894, ISO/IEC 42005)
• Industry-led best practices or codes of conduct

Zaion's collaboration takes place mainly through its existing working relationships rather than formal external initiatives. We work with the organisations deploying our systems to define the scope of each use case and the safeguards appropriate to it, and with our cloud and model suppliers on the security, privacy and reliability of the components we integrate. Internally, our technical, security, compliance and product functions address AI risk together within a shared governance framework. We also follow the work of standards bodies, regulators and industry groups relevant to our sector.

Risk management is built into the services as layered automatic controls rather than sitting only in documents : 
- Preventive: allowlists of models, actions and tools; input validation; personal-data masking; token caps. 
- Detective: typed traces, metrics, loop detection, an alignment quality signal. 
- Corrective: fallback providers, circuit breaker, retry without tools, fail-closed bleeping, and a safe default response that hands an explicit error state back to the orchestrator rather than improvising.
The three system types are managed differently. 
- Generative: risk comes mainly from third-party model behaviour, managed by output schema validation, content-filter handling and provider fallback. 
- Agentic: bounded steps, action allowlist, loop detection. 
- The discriminative personal-data model: threshold calibration on a gold set and fail-closed design.
Above that, the six-gate lifecycle governs progression, each gate with a named condition and a named approver, and escalation running from the AI Lead to the CISO to top management.
Cadence : Every release re-runs tests and metrics. Every new model version triggers gold-set re-evaluation. Every provider change updates the allowlist. Incidents and findings trigger a fix plus a regression test. 
- Quarterly: model performance, data quality, audit findings, objectives, risk treatment, impact assessment coverage, and an operational status report. 
- Monthly: incident analysis. 
- Twice a year: supplier compliance, performance reporting to leadership, data quality review. 
- Annually: internal audit across seven areas, refreshed impact assessments, gap assessment, training completion, management review, and review of every policy. Registers and provenance records are kept at least three years or for the operational life of the system.

Quality dimensions are defined and measured for every dataset: accuracy, completeness, consistency, timeliness, representativeness, and bias and fairness. Thresholds: completeness at or above 95%, operational data refreshed within 30 days, fairness variance below 10% across demographic groups. 
Bias and representativeness results must be reviewed before any production deployment, and live systems get a further data quality review at least every six months. For the retrieval-based chatbot we also track knowledge-base freshness, accuracy and completeness, and limit irrelevant context using a similarity threshold and metadata filters.
We also run gender-stratified evaluation of our speech models against our fairness target, and expert linguists review model and voice quality.
Known limitations, recorded rather than hidden. 

Zaion Lab - our AI research team, and our infra and security team oversees secure testing of the AI services. Responsibility is shared with Infrastructure and Security, who hold custody of production data, environments and secrets, and with the platform and product teams.
Separation of duties applies: people who develop a system cannot be its sole approvers or auditors, and internal auditors cannot audit areas they are operationally responsible for. Where team size makes overlap unavoidable, compensating controls such as peer review and management sign-off are documented.

• Maintain a copyright policy that addresses data sourcing, content provenance, safeguards, and organizational roles and responsibilities
• Apply provenance controls to guard against training data being sourced from websites or repositories that have been determined to engage in large-scale piracy
• Refrain from the unlawful circumvention of technological protection measures in data sourcing
• Conduct data cleaning, qualification, and/or tokenization activities as part of a transformative data preparation process
• Consult and/or retain an intellectual property attorney to protect, enforce, and comply with, intellectual property rights.

• Restricting outputs that raise ethical, human rights, or legal concerns—such as non-consensual intimate imagery, unauthorized deepfakes, or outputs that are substantially similar to copyrighted works.
• Filtering results using keyword or image-based restrictions to reduce risks of misuse

Minimisation and pseudonymisation are the centre of the design, not an add-on.
The anonymisation service removes personal data from call transcripts and returns bleep ranges for the audio. Before any prompt, conversation history or tool output reaches a language model, the gateway can replace emails, phone numbers, bank details, social security numbers and URLs with reversible placeholders, restoring them only in the response that goes back to the customer. Sensitive variables can be hidden from the model entirely. Detection is deliberately tuned for recall: a word is masked as soon as it reaches a 10% probability of being personal data, and if transcript-to-audio alignment quality falls below 80% the service bleeps the whole utterance rather than risk a partial leak.
Neither shared service persists conversation content. Processing is in-memory, agent memory is cleared after each request, and the cache holds counters and identifiers only, with expiry.
Data is encrypted with AES-256 at rest and TLS in transit, with least-privilege access, per-tenant segregation and secrets held in a dedicated vault scoped per workspace. Personal data in development and test environments must be anonymised or pseudonymised unless the DPO formally approves otherwise. A data protection impact assessment is required before deploying any system that processes personal data.
Providers are treated as sub-processors with documented records confirming that no Zaion or client data trains their models. Client data remains the client's property, and its reuse for training or for other clients is contractually excluded. Customers configure masking and processing choices per workspace and per request.
Where the data sits. Production workloads run on cloud infrastructure in EU regions, with object storage encrypted server-side and reachable only through scoped roles. Managed databases run on private cloud in France - Paris, Marseille and Lyon - encrypted at rest and reachable only through private endpoints. Some legacy infrastructure remains elsewhere in the EU and is being consolidated. Cloud suppliers must hold ISO 27001 and SOC 2, confirm EU data residency, and have a data processing agreement in place.

• Conduct regular cybersecurity risk and vulnerability assessments tailored to AI models or systems
• Perform threat modeling that includes AI-specific risks (e.g., data poisoning, prompt injection)
• Maintain or update security policies aligned with recognized standards (e.g., NIST CSF, ISO/IEC 27001, SOC 2, CIS Critical Security Controls), and review them regularly in response to emerging risks or regulatory guidance
• Maintain vulnerability management processes (scanning, channels for external reporting, patching, remediation)
• Implement incident response, disaster recovery, or business continuity plans, including escalation procedures for high-severity incidents
• Train staff on cybersecurity best practices and AI-specific threats, including how to recognize and respond to misuse or unintended outcomes of advanced AI systems
• Integrate cybersecurity AI risks into broader cybersecurity risk management activities
• Regularly review security measures and update them in response to emerging risks, incidents, or major releases

• Apply multi-factor authentication (MFA) and role-based access controls for advanced AI systems
• Encrypt AI assets (datasets, models, configurations) in storage and in transit as appropriate
• Monitor system activity and log access to detect anomalies or misuse
• Conduct secure AI development and/or deployment practices
• Conduct security testing focused on AI-specific risks (e.g., red-teaming, adversarial testing, stress tests)

• Limit access to proprietary AI assets based on role or need-to-know
• Store model weights, datasets, and algorithms in secure, access-controlled environments
• Track and log access to sensitive AI resources
• Require NDAs or confidentiality agreements for staff and contractors with access

• Conduct pre-employment screening or role-sensitive vetting
• Monitor for unauthorized internal access or suspicious activity
• Provide staff training on cybersecurity best practices and AI-specific threats
• Implement insider-risk escalation or response procedures

- AES-256 at rest and TLS in transit. Least-privilege access and per-tenant segregation. Secrets in a dedicated vault with workload authentication and per-workspace isolation. API-key authentication separating user and administrative scopes. Rate limiting, per-call request caps and token budgets, which protect against cost and abuse attacks as much as against load. Input validation through strict schemas, transcript and timestamp validation, and bounded conversation history. Allowlists for models and for agent actions. Provider content filtering. Circuit breaker and fallbacks for availability. Containers built from minimal images, run non-root and pinned by digest.
- Model weights are kept out of source control and out of container images; provider credentials never appear in code; personal data is masked before anything reaches a third-party model. Model artefacts and training data sit in encrypted storage reachable only through scoped roles, with versioning and audit-log immutability. All AI assets carry a security classification, and the production engines are classified Confidential.
The AI-specific threat surface is treated as a security matter rather than a quality one. Threat modelling covers data poisoning, prompt injection and agentic security. In a voice product the caller's own speech is untrusted input reaching a model, which is exactly why bounded scope, allowlists, loop detection and refuse-and-escalate behaviour function as security controls. Production monitoring covers adversarial attacks, data poisoning and unusual inference patterns.
Some responsibilities are contractually delegated: physical security of compute and storage sits with our cloud providers, who must evidence ISO 27001, SOC 2 and EU data residency and are assessed annually. 

• Constraints on the agent's action space (e.g., tool-use permissions, environment sandboxing, allowlists/blocklists of resources, scope limits per task)
• Human oversight or interruptibility mechanisms (approval requirements for sensitive actions, escalation paths, interruption interfaces)
• Monitoring (anomaly detection, multi-agent interaction monitoring)
• Logging of agent actions

Evaluation and performance results are shared primarily with the organisations deploying our systems, under the confidentiality terms of our client agreements, through service documentation and regular service reviews. Results are reported to internal leadership as part of our management review cycle, and to regulators where required. Material is adapted to its audience, with plain-language summaries provided for non-technical readers where appropriate.

Information on data sources is provided to clients and downstream partners rather than published openly. We maintain a structured register recording, for every dataset, its source and provenance, rights and licences, privacy check, type and category, what it is used for, refresh cadence, labelling and preparation method, documented bias and risk notes, retention reference, lawful basis and owner.
Training data for third-party speech and language components is governed by those providers' own documentation, with our agreements confirming that our data does not train their models.

Yes, for the users of our conversational IA solutions (Voice AI Agent, Chat AI Agent), the transparency measure with the widest reach is disclosure at the moment of interaction, mandated per product. AI Agent gives the use a clear notice at the start of the call. Agent-Assist is visible in the agent interface

AI risk management is embedded through an ISO/IEC 42001-aligned AI management system: 
- Accountability. The CISO, who is also Head of Infrastructure and Security, is accountable for AI governance and for every AI policy; the AI Lead is responsible for implementation. Top management holds final authority: it approves major objectives and resourcing, reviews risk reports and audit findings, formally accepts or rejects residual risk that cannot be mitigated, and approves major external AI communications.
Zaion Lab documents systems, datasets and model cards. Infrastructure and Security hold custody of production data, environments and secrets. Service owners flag and escalate open risks for management sign-off. Separation of duties is mandatory throughout.
Our governance is deliberately lightweight for our size: named ownership of every AI decision and risk, AI risk and performance reported directly to the CISO and top management, and leadership, technical teams and compliance working inside one shared framework rather than through layers of committees.

Training is role-based, at appointment or onboarding and annually thereafter. The AI Lead takes ISO 42001 foundation training plus AI ethics and governance. The CISO takes ISO 27001 implementer training plus AI security awareness. Product and engineering take secure development, AI ethics and responsible AI principles. The DPO and compliance take data protection, EU AI Act awareness and ISO 42001 foundation. Every employee takes AI ethics awareness, acceptable use of AI tools, and the basics of bias and fairness. Completion is tracked by HR and reported to the CISO. Delivered courses include ISO 42001 foundation, an internal AI ethics course and a fairness testing workshop.
For engineering teams this is reinforced operationally: onboarding through detailed service documentation - configuration guides, test and staging acceptance plans, findings reports - plus code review and knowledge sharing between research and platform teams. AI management policies are published internally for all relevant staff.

Incidents are recorded and reviewed as part of the management review. Technical incident data is captured automatically alongside it: structured traces recording error type, description, provider and model, and warnings; logs carrying request identifiers and session context; and metrics. Fixes are recorded in version history together with a regression test, and analyses are written up as findings documents. Records are kept at least three years or for the operational life of the system.

• ISO/IEC standards (e.g., ISO/IEC 27001, ISO/IEC 42001)
• Industry-led best practices or codes of conduct

ISO/IEC 42001 is the framework for our AI management system, with a full statement of applicability covering every clause and control, each assessed and tracked individually. Our data management policy and register are aligned to its data acquisition, quality, provenance and preparation controls, with model cards and impact assessments per system. It is integrated with our ISO/IEC 27001 information security management system, sharing governance, policy hierarchy and audit cycles.

Disclosure is mandated per product. AI Agent (Voice and Chat) gives the end-user a clear notice at the start of the interaction. Agent-Assist is visible in the agent interface. BotCenter and Zaion Assistant carries a notice in the admin interface. Wording held in our documentation includes phrasing along the lines of 'you are being assisted by an automated AI system' and 'this call is handled by an automated voice AI'.
Disclosure must be visible and prominent rather than buried in terms and conditions, in plain language suited to the audience, and delivered at the point of interaction. Documentation must also explain how to override or stop the AI, how to escalate to a human, and where human review is expected - with particular weight on decisions that significantly affect an individual. Failing to disclose AI interaction is an enforceable policy breach.

In-house research on privacy-preserving speech analytics. We built a multilingual personal-data detection using model-assisted annotation at scale with recall-oriented calibration, entity gap-filling so partial matches cannot leak half an identifier, quantisation-aware training and optimised inference, and timestamp alignment for audio bleeping with fail-closed behaviour when alignment quality drops.
We are also work with Academic actors through Thesis programs to advance system performance and outcomes and publish open-source models for the French IA community. 

We focus on low footprint environmental and computational efficiency for our proprietary models. We choose CPU-first models where they are adequate rather than defaulting to accelerators. Compute footprint is monitored as part of resource management, with autoscaling and storage lifecycle policies.
We defend a hybrid approach where small models are used when needed and when sufficient, both for classification tasks (NLU) or the use of SLM when no reasoning power is needed.