EuroAIGuard Conseil: G7 Hiroshima AI Process (HAIP) Transparency Report

Formal thresholds : We apply a documented risk methodology (ISO/IEC 27001 §6.1.2–6.1.3, in force in version 1.0). Criticality = likelihood × impact on a 4×4 matrix, retaining the highest impact across confidentiality, integrity and availability.  Four bands graduate both the deadline and the conditions for accepting a risk :  1 to 3 acceptable as it stands , 4 to 6 treatment within 12 months or reasoned acceptance by the direction,  8 to 9 treatment within 3 months, acceptance only with a documented compensating control , 12 to 16 immediate treatment, no acceptance in any state. That top band is our operational definition of an unreasonable risk.

Limits set at zero :  No client engagement data and no directly collected contact data pass through AI tools, only professional information already public on the open web,  no client data entered into our platform ever passes through an AI tool,  no AI tool performs an outbound action.

Answered by design :  Our compliance software embeds, calls and trains no AI model,  it is a deterministic rule engine, recorded as such in our ISMS scope. A compliance determination that is not reproducible is a risk we judged unacceptable to place in a client's hands. If any AI component were ever integrated, our secure development policy requires a dedicated AI management perimeter to be opened before production release.

Agentic AI :  Two internal agents support research on public sources, recorded in our own AI inventory with EU AI Act classification,  per-action permission gating, no autonomous outbound action, validation by a named human before any output leaves.

Generative AI : A production charter dated 11 July 2026 binds every AI-assisted session, every regulatory figure verified against a primary source before it is written, never from memory, and human validation before anything leaves.

Evidence :  Before adoption, each third-party AI tool is assessed in writing against our security policy, contractual terms, model-training settings, data retention, international transfers, connectors, account security. The residual risk is stated explicitly.

Sign-off : Adoption and its residual risk are recorded in a direction approval memo.

Caveat on metrics : As a deployer we have no visibility into a third-party model's internals and run no model-level evaluation. Our assurance comes not from what a model scores but from bounding what it can reach and what it can do.

Safeguards : Data-minimisation rule fixing what may never be processed  per-action permission gating,  no autonomous outbound action,  validation by a named human before any output leaves. Permanent restrictions, not a release phase.

After deployment :  AI events fall under our security incident procedure and register, the AI-tool account is covered by the quarterly access review  risks are re-examined at the quarterly management review.

Incidents are governed by a documented procedure and recorded in a single living register. Detection sources are defined and include reports from clients or third parties through a published contact channel, alongside monitoring alerts, audit logs, CVE watch and direct observation.

Every suspicious event is logged at detection, even if later requalified as a false alarm, the requalification itself is part of the record. Entries are append-only, never edited away.

How access is determined. Three logics, none of them discretionary. Our published channel is open unconditionally to anyone, with no filtering by stakeholder type. Notification to authorities is triggered by legal obligation rather than by our own judgement of who should be told. Notification to clients is triggered by our incident procedure. Severity governs what must be assessed rather than who may report. From grade three upwards, the personal-data dimension is systematically assessed and the conclusion is written to the register even when it is negative.

Receiving. Our incident procedure names a published channel, contact@euroaiguard.com, for reports from clients or third parties, alongside monitoring alerts, audit logs and CVE watch on our dependencies.

Sharing. Where an incident affects personal data, we notify the French supervisory authority within 72 hours under GDPR Article 33, and affected clients within 48 hours under the commitment set in our incident procedure for our processor role. The notification decision, including a reasoned decision not to notify, is recorded in the incident register.

On the table above. Our single published channel is open to anyone, which is why most rows are marked as available ad hoc rather than as standing arrangements. The organisation is founder-operated and has no employee, so that row is marked not currently accessible because the stakeholder group does not exist, not because a channel was withheld.

Limits, stated plainly. We operate no dedicated vulnerability disclosure policy or bug bounty, and we participate in no incident-sharing community. At our size, reporting flows through the named channel above and through our supplier and client contractual chains.

• Reporting to regulatory authorities as relevant

To the supervisory authority :  where personal data is affected , the content required by GDPR Article 33(3), nature of the breach, categories and approximate volume of data subjects and records concerned, likely consequences, and the measures taken or proposed. 

To affected clients:  where we act as processor ,  the nature of the incident, which of their data is concerned, the timeline, and the measures taken.

Along the supplier chain : notifications received from suppliers, including changes of sub-processor, are relayed to affected clients the same day, with the notice and objection periods we owe them.

• ISO/IEC standards (e.g., ISO/IEC 27001, ISO/IEC 42001, ISO/IEC 23894, ISO/IEC 42005)

Pilot with  industry partner :  we run a pilot with a partner organisation. The collaboration is explicitly risk-oriented.

Advisory engagements with deploying organisations : Where we work with an organisation deploying AI, the engagement is itself the collaboration, we assess their AI systems against the EU AI Act and ISO/IEC 42001 with them, and the mitigation measures are adopted by them, not prescribed by us.

Supply chain : We completed a full review of our suppliers' data processing agreements in 2026, recording per-supplier points of attention rather than filing them unread, and we hold a commitment to relay any change of sub-processor to affected clients the same day, within the notice periods we owe them.

Multi-stakeholder. This reporting framework is our participation. We joined it as a small deployer to document, at the smallest organisational scale, what the Code of Conduct looks like in practice.

 We deploy AI, we do not build it , with no model metrics to rely on, our assurance comes from containment rather than measurement. Two boundaries,  what may enter an AI tool, and what may leave it. Every other practice serves one of them.

Our chain : A written supplier evaluation feeds a direction decision, which fixes the limits before use  data-minimisation in, per-action gating and named human validation out. In operation, anything anomalous enters an append-only incident register at detection. Each entry carries a root cause  structural causes are carried into the risk treatment plan rather than closed locally, and the affected risk rating is re-examined.

Cadence : Management and access reviews quarterly,  restoration test half-yearly, policy review and awareness session annually.

Triggers between cycles : Any recorded incident,  a new AI tool,  a supplier changing sub-processor , a structural root cause,  a regulatory change, as with the recent revision of the EU AI Act calendar.

By type : Generative use,  the severe risk is an incorrect regulatory statement reaching a client or the public, controlled by primary-source verification and human validation. Agentic use, the severe risk is autonomous action, controlled by per-action gating, no outbound action, and periodic review of the connector surface.

Not applicable at the training stage : We collect and curate no training data, run no fine-tuning, and operate no moderation tooling. Dataset audits, training-data filtering and generalisability assessment belong to the model developers whose systems we deploy, not to us.

On fairness : our compliance platform is a deterministic rule engine. It cannot acquire bias from data. Identical inputs always yield identical classifications, and every result is traceable to the rule that produced it. 

• Not applicable

• Not applicable

Framework :GDPR in both of our roles,  controller for our own processing, and Article 28 processor for the data our clients enter into our platform. Security follows ISO/IEC 27001. We work from EDPB and French supervisory authority guidance.

Records and agreements. Article 30 records maintained for both roles, controller and processor. A model Article 28 data processing agreement for the processor role. Our suppliers' agreements were fully reviewed and archived.

Technical measures : Encryption in transit, TLS 1.2 minimum with HSTS. Multi-tenant isolation enforced by systematic filtering on every data query and covered by dedicated test suites. Role-based access control with server-side guards. Systematic audit logging recording identity, organisation, address and before/after detail.

Breach handling : Supervisory authority within 72 hours under Article 33, affected clients within 48 hours under our agreement, with the notification decision recorded either way.

For AI specifically: the measure is exclusion rather than protection, client data never enters an AI tool, and our platform embeds no model, so it never reaches one.

Limits, stated plainly : Encryption at rest is delegated to our infrastructure provider ,  application-level field encryption is under evaluation, not in place. Automated purge of audit logs at twelve months is decided but not yet implemented. 

• 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
• 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
• These responsibilities are delegated contractually to model or infrastructure providers
• Other(s) (specify): Two clarifications. Our AI-related security risks are not managed in a separate process , they are folded into our ISMS. The AI tool provider went through the same supplier evaluation as any other, the residual risk was accepted by the direction in writing, the account used for AI tools is covered by the quarterly access review, and AI-related events fall under our general incident procedure and register. On delegation , physical and environmental security and encryption at rest are delegated contractually to our infrastructure providers, whose agreements we reviewed and archived in 2026. No such delegation exists towards the provider of the models we use : we hold no data processing agreement with it, and we say so rather than let the checkbox imply otherwise. That gap is precisely why our primary control is minimisation of what may enter the tool at all.

• Monitor system activity and log access to detect anomalies or misuse
• Conduct secure AI development and/or deployment practices
• These responsibilities are delegated contractually to model or infrastructure providers
• Other(s) (please specify): As a deployer, our technical controls sit at the boundary rather than inside the model. Before use, each AI tool's reachable surface is assessed which connectors and integrations it can access, and what it can do without human action. In operation, per-action permission gating applies, no AI tool performs an outbound action, and every output is validated by a named human before it leaves. Physical and environmental security of the infrastructure we use is delegated contractually to certified providers, no equivalent delegation exists towards the provider of the models themselves.

• Limit access to proprietary AI assets based on role or need-to-know
• Track and log access to sensitive AI resources
• These responsibilities are delegated contractually to model or infrastructure providers
• Other (please specify): On protection of AI assets, we hold no model weights, no training datasets and no proprietary model. What we protect is narrower, namely the source code of a deterministic rule engine held in private repositories with multi-factor authentication, and the credentials giving access to the third-party AI tools we use. The checkbox options in this subsection assume ownership of AI assets we do not have, and we select Other to say so rather than let the boxes imply otherwise.

• Monitor for unauthorized internal access or suspicious activity
• Implement insider-risk escalation or response procedures
• These responsibilities are delegated contractually to model or infrastructure providers

Framework. An ISO/IEC 27001 information security management system, in force in version 1.0 

Access and identity : Least privilege, need-to-know, attributability and revocation by default as stated principles. Role-based access control in the application with server-side enforcement, multi-factor authentication on supplier accounts, and a quarterly access review covering unknown users, unknown tokens and authorised third-party applications.

Application and data : Tenant isolation enforced on every data query and covered by dedicated test suites. Modern password hashing, anti-forgery protection, data access through an ORM rather than assembled queries, input validation, a full set of security response headers, and distributed rate limiting. Encryption in transit at TLS 1.2 or above.

Secrets and supply chain : No secret in source code, configuration by environment variables, secret files excluded from versioning, and a "zero secret in the repository" check at every internal audit. Dependencies pinned to exact versions with a traced vulnerability watch and defined correction deadlines.

On particularly sensitive AI assets. We hold none in the usual sense, no model weights, no training datasets, no proprietary model. What is sensitive is narrower, the credentials granting access to the third-party AI tools we use, and the source code of our deterministic rule engine. Both fall under the regime above · private repositories with multi-factor authentication, secrets never committed, and the AI-tool account included in the quarterly access review.

One limit: Encryption at rest is delegated to our infrastructure providers,  application-level field encryption is under evaluation and not in place.

• 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)

This kind of report is our disclosure open to anyone, governments, peers, clients, civil society. For a deployer of our size that is the most complete and the most accountable channel available, and we chose it deliberately.

We evaluate suppliers, not models. Each AI tool is assessed before use and the residual risk is accepted in writing by the direction. That assessment is where our assurance comes from, and it is an internal record what belongs in public is the governance around it, which is what this report sets out.

Clients get more : A security posture document on request, and full answers to supplier security questionnaires.

Plain language is our default, not an add-on : We write for data protection officers and compliance leads, in French and English. We publish nothing that needs machine learning expertise to read, because we produce nothing of the kind.

https://www.euroaiguard.com/confidentialite/

Our public privacy policy addresses the processing of personal data. It does not address user prompts or the outputs of advanced AI systems, because our platform processes neither, it embeds no AI model, so there is no prompt and no model output involved in the service we provide.

not applicable to us

Advisory versus decision : Our methodology draws the line explicitly , analysis may be prepared with tool assistance, decision belongs to the direction. Written supplier evaluations, risk ratings and incident findings are advisory inputs. None of them decides. We have no advisory body and no committee, and we do not describe our own judgement as one.

Final accountability :  For now,  the direction owns every risk in the register and signs every acceptance of residual risk. The memo bringing the management system into force carries a name, a place and a date. Accountability here is a signature, not an org chart.

Cadence :  Management review and access review quarterly. Backup restoration test half-yearly. Policy review and awareness session annually.

Between cycles, four things force a review. An incident whose root cause proves structural rather than one-off. Adoption of a new AI tool, which requires its own evaluation and its own decision. A supplier notifying a change of sub-processor. A regulatory change,  the revision of the EU AI Act timetable was entered as an external-context input at our management review rather than noted and forgotten.

We wrote these governance policies and this risk methodology, and apply them daily, which is a stronger form of familiarity than attending a session on them. Competence is maintained deliberately rather than assumed,  continuous professional development in AI governance and data protection, including preparation for a recognised professional certification in AI governance, and an ongoing regulatory watch whose findings are entered as external-context inputs at our management review.

Our management system also institutes an annual awareness session that applies to the founder and is attested like any other control. It falls due within the first annual cycle and has not yet been held (we report the state, not the intention).

Incidents are recorded in a single living register governed by a documented procedure. Entries are append-only,  a correction is made by adding, never by erasing, and an event requalified as a false alarm keeps its trace because the requalification is itself part of the evidence.

Each entry carries the detection, a severity grade, a factual description, a timeline, preserved evidence, a personal-data assessment with the notification decision, a root-cause analysis, corrective actions with owner and deadline, the lessons drawn, and a closure validated by the direction. Where a root cause proves structural rather than one-off, the corrective action is carried into the risk treatment plan rather than closed locally.

The register is internal and stays internal. In the interest of accuracy, it holds no entry to date (the process is in force).

Yes, best practices rather than research. We publish practitioner guidance on managing AI and data protection risk, written analyses of regulatory developments, and a set of practical guides  covering EU AI Act readiness for SMEs, ISO/IEC 42001, NIS2, DORA, the GDPR and AI, together with an impact assessment checklist and a register template.

Our published material also covers the risks of using AI in one's own work, including the effect of unexamined reliance on generative tools on the user's own understanding, with concrete counter-practices rather than warnings.

This report is part of the same intent,  we joined the framework as a small deployer to document, at the smallest organisational scale, what the Code of Conduct looks like when actually applied.

We conduct and publish no academic research and take part in no research consortium.

• ISO/IEC standards (e.g., ISO/IEC 27001, ISO/IEC 42001)

ISO/IEC 27001:  our information security management system is the frame within which AI risk is handled. We run no separate process for AI  supplier evaluation, access review, incident procedure and management review are the same for AI as for everything else.

The EU AI Act :  we apply its risk categories to classify the AI systems we deploy, in our own inventory.

The Hiroshima Process International Code of Conduct : we commit to it by submitting this report, and the reporting framework is its concrete application.

One precision we think is owed , we track ISO/IEC 42001 as a reference framework inside the tool we provide to clients. We operate no AI management system in the sense of that standard for ourselves, and we claim none.

The two AI agents we deploy are internal. They interact with no one outside the organisation, take no outbound action, and produce nothing that reaches a third party without a named human validating it first.

One point we prefer to state rather than leave unsaid : Some of our published material is drafted with AI assistance, and we do not label it as such. That is a documented decision of the direction, not an omission, every published item carries named human editorial responsibility, and our production charter requires verification against primary sources and human validation before anything is published. We took the view that named accountability for the text is the substantive guarantee, and that a generic label would add less than it suggests.

We publish practitioner guides : EU AI Act readiness for smaller organisations, ISO/IEC 42001, NIS2, the GDPR and AI, plus an impact assessment checklist and a record template.

We also produce AI literacy training modules answering the AI Act's literacy duty, what AI systems are, what they can and cannot do, and where the obligations fall. We report no delivery figures because the material has not yet been delivered commercially.

Our articles address the limits of AI from the user's side, including the effect of unexamined reliance on generative tools on one's own understanding.

On underserved audiences  we aim at small and founder-operated organisations, structurally underserved because AI governance advice is priced for large enterprises. We run no school or university partnership, no public education programme and no community workshop, and claim no outreach to communities we do not serve.