G7 cyber warning puts AI security on the SME agenda

The useful part of the G7’s latest cyber declaration is not the communique language. It is the way AI security has been placed next to post-quantum cryptography, telecoms resilience and SME protection as an infrastructure issue, not as a laboratory problem.

On 8 June 2026, ANSSI published the declaration issued after the G7 Cybersecurity Working Group’s 27 May plenary meeting. The European Commission welcomed it two days later, highlighting four priorities: post-quantum migration, cybersecurity risks from and to AI systems, telecoms cybersecurity, and support for SMEs. For a small European firm, the message is narrower and more practical: if an AI system enters the company, its security evidence enters procurement.

AI risk is now supply-chain risk

The declaration treats generative AI and large language models as double-edged security assets. They can help with vulnerability discovery, code generation and incident response. They can also be used by attackers, poisoned by bad inputs, exposed through data leakage or weakened by opaque dependencies.

That framing is different from the usual SME conversation about AI, which still tends to start with productivity. The cybersecurity question starts somewhere else: what components are inside the system, who maintains them, what data can they see, how fast can a vulnerability be acted on, and which supplier is responsible when the stack changes?

Most SMEs will not audit a foundation model. They may not even be able to see one directly. But they can ask for evidence at the layer they buy: the chatbot provider, the workflow vendor, the code assistant, the managed service provider, or the integrator wrapping a model into a sector tool. AI security becomes a chain of representations. The weaker the representations, the harder it is to trust the deployment.

The AI SBOM is a useful proxy

The most concrete artefact around the G7 work is the Software Bill of Materials for AI minimum-elements guidance. CISA describes it as recommendations to be considered alongside ordinary SBOM minimum elements because AI systems are still software systems. ANSSI’s accompanying publication says an AI SBOM improves transparency and traceability by mapping the AI supply chain, deployed components and dependencies.

For an SME buyer, that does not mean every vendor must hand over a perfect machine-readable AI SBOM tomorrow. The market is not there yet. It does mean the idea gives procurement a better checklist than “is your AI secure?”

Evidence item	What it tells the buyer
Model identity and version	Whether a deployed system changed after testing or approval
Software dependencies	Which libraries, packages and services can introduce vulnerabilities
Data-processing boundary	What customer, employee or operational data can enter the system
Third-party components	Which external model, API, vector database or hosting layer matters
Update and patch process	How security fixes reach the live system
Vulnerability disclosure route	Where a researcher, customer or buyer reports a weakness
Incident notification	How the supplier will warn the SME if AI-related compromise occurs

Source: G7 AI SBOM minimum-elements guidance, ANSSI AI SBOM publication and European Commission G7 cybersecurity summary. Last verified 2026-06-16.

The point is not paperwork for its own sake. It is response time. If a dependency is compromised, a hosted model is withdrawn, a connector leaks data, or a prompt-injection flaw affects a customer-facing workflow, the business needs to know which supplier can answer which question.

Secure by design is moving into contracts

The G7 declaration’s SME section echoes the EU Cyber Resilience Act: products should be secure by design, security should continue through the lifecycle, and small firms should get usable guidance rather than enterprise theatre. The Commission’s CRA implementation page says the rulebook covers digital-product security across design, updates and maintenance.

That matters because AI procurement often sits between software and service. A small company may buy a SaaS tool, connect it to a CRM, feed it support tickets, let it draft code, and then discover that nobody internally owns the security model. The vendor calls it a service. The business experiences it as infrastructure.

The contract should close that gap. A useful AI supplier clause does not need to be dramatic. It should say which components are under the supplier’s control, how security updates are handled, whether customer data is used for training or evaluation, whether logs can be exported for investigation, what subcontractors matter, and how soon the supplier will notify the customer of a relevant incident.

For AI systems that touch sensitive workflows, the same clause should ask for stronger evidence: security architecture notes, independent test summaries, model or service versioning, an AI SBOM where available, and a named channel for vulnerability disclosure.

Not every AI tool deserves the same file

The risk-based move for SMEs is to avoid both extremes. Ignoring AI security is too casual. Treating every office assistant as critical infrastructure is not credible either.

Start with four questions:

1. Does the AI system see customer, employee, financial, source-code or regulated data?
2. Can the system change an operational process, not just draft text for a person?
3. Does the system connect to live business tools such as email, CRM, ERP, ticketing, repositories or identity systems?
4. Would an outage, data leak or manipulated output create a material business or legal problem?

If the answer is mostly no, keep the record light: vendor name, purpose, data boundary, basic security statement, owner and review date. If the answer is yes, build a supplier-evidence file. The file should be short enough to maintain, but specific enough that a replacement manager could understand the risk in ten minutes.

AI-assisted code needs special treatment

The Commission’s G7 summary calls out AI-assisted vulnerability discovery and AI-assisted code generation as emerging cyber capabilities. That is where many SMEs will feel the issue first. A developer assistant can accelerate delivery, but it also touches repositories, secrets, dependency choices and insecure patterns.

The minimum control is not a ban. It is to decide where AI code assistance is allowed, where it is not, and what evidence remains after use. Teams should keep secrets out of prompts, review generated code like junior code, run dependency and static checks, and document whether the tool can train on submitted code. When a supplier or agency delivers software, the buyer should ask whether AI-generated code was used and which review process caught security-sensitive output.

That question is not moral. It is operational. If a vulnerability is later found in a generated function, the company needs a path to understand how it entered the codebase, whether similar patterns exist elsewhere and which supplier evidence applies.

The practical next step

The next step is a one-page AI security register, not a transformation programme. List the AI systems in use, the supplier, the workflow, the data exposed, the owner, the current evidence and the next missing answer.

Then pick the two highest-risk systems and ask their suppliers for the evidence that maps to the G7 direction: components, dependencies, security updates, vulnerability handling, incident notification and data boundaries. If the supplier cannot answer in full, record the gap and decide whether the system is still acceptable for the workflow it touches.

The G7 declaration does not give SMEs a new law to comply with this week. It gives them a clearer signal about where serious buyers are heading. AI security will be judged less by confident vendor language and more by traceable components, update paths and incident answers. That is manageable work, but only if it starts before the first breach or customer questionnaire.