Direct answer. My decision record for a European AI company does not start with its headquarters or brand. It records the entity that signs and the service it provides. It also tracks the data path, dependencies, and operating duties. Last, it sets the evidence needed and the exit terms. This page is a dated note on my method. It is not a ranking or a test. It does not select a supplier. The ENISA framework supports a review of several layers of an AI system (ENISA). The Commission presents the European AI Act through a risk-based approach (European Commission).
Official sources checked on 20 October 2026.
What I record before considering a supplier
I start with the workflow in question. I also note the evidence that the team must keep. A company's stated nationality remains one item in the record. It does not describe the whole service being bought.
My record includes at least:
- the contracting entity and the other entities involved.
- the service provided, including support and the components used.
- the path taken by data, logs, and backups.
- technical dependencies and subcontractors.
- the people responsible for the workflow, its monitoring, and its shutdown.
- the evidence to obtain before the pilot.
- the terms for export, access revocation, and deletion.
This method does not turn a European address into evidence about the service. It requires every statement to be tied to a document and a precise scope.
What does a European AI company mean in this record?
I use a working definition here. A company may be based in Europe. It may sign through a given entity. Its service may also depend on other groups or systems. The record therefore separates legal identity from the product bought. It also separates data flows from the chain of responsibility.
The Commission links the European approach to AI with excellence and trust (European Commission). It also says that AI Factories use EuroHPC computing power. They support AI development and innovation in Europe (European Commission). These facts give a European context. They prove nothing about a given supplier.
For a decision, "European" is one field in the record. The useful question remains simple. Which entity provides what? What are its dependencies and roles?
Why are headquarters not enough?
Headquarters indicate where a company is established. On their own, they do not document processing regions, backups, support access, components, or subcontractors.
The ENISA framework reviews cyber security practices across several layers of an AI system (ENISA). I use that way of reading in my record. I do not treat it as a certificate or proof of compliance. I do not present it as an ENISA endorsement of my framework.
The following table is my collection framework. It connects each question to verifiable evidence.
| Question to document | Evidence requested | Point to record |
|---|---|---|
| Which entity signs, and which other parties are involved? | Contract, entity names, and the role of each party. | The chain of responsibility. |
| Where do the data, logs, and backups go? | Flow diagram, relevant locations, and retention rules. | The scope processed and kept. |
| Which subcontractors and components are involved? | Current list, function of each party, and change notices. | The service dependencies. |
| Which measures can be reviewed? | Documents, controls, reports, or attestations suited to the case. | The evidence and its scope. |
| How can the service be stopped and useful materials recovered? | Export formats, return of materials, revocation, and planned deletion. | The exit process. |
What evidence I request before a pilot
In my method, evidence must have a date and link to the service bought. The person who checks it must be able to read it. A general claim does not replace proof from the contract or a technical record.
Before using real data, I request:
- a diagram of the workflow, connected systems, and data flows.
- a list of the entities, subcontractors, infrastructure, and relevant locations.
- the rules for retention, deletion, support access, and data use.
- security evidence suited to the case, along with incident and exit procedures.
I then link each item of evidence to a question in the record. The ENISA framework helps with a review of several layers of an AI system. It does not certify the supplier or the method shown here (ENISA).
To define the scope and the expected evidence, I also use this AI project requirements document.
How I map data and dependencies
I map the path of each type of data through the workflow. I note its source and the component that gets it. I add the logs, backups, and support access. Last, I note the system that gets the output. The document separates operations, human access, connectors, and test systems.
For each subcontractor or dependency, I record:
- its function in the service.
- the data concerned.
- the relevant locations.
- the process for telling the buyer about a change.
- the options available to the buyer.
This map remains tied to the contract and the technical diagram. It makes dependencies visible in the decision.
What legal boundary I set for the European AI Act
The European AI Act is Regulation (EU) 2024/1689, and its framework uses a risk-based approach as presented by the Commission (European Commission).
I do not classify the reader's system here. I do not infer any duty or give legal advice (European Commission). For a given case, start with official sources. Then ask qualified people to review it (European Commission).
In my record, I only document the facts needed for that review:
- the decision or action influenced by the workflow.
- the parties that provide, deploy, configure, use, and monitor its components.
- the people who may be affected by an output.
- the planned records, human reviews, and routes for appeal.
These questions prepare the case for review. They do not amount to a regulatory classification or a conclusion about compliance (European Commission).
Buy, commission, or build: who is responsible for what?
I do not decide the form of the solution before I assign responsibilities. The table below records what the team keeps or gives to others. It also records the proof tied to each commitment.
| Area | Responsibility to assign | Evidence to retain |
|---|---|---|
| Data | Approve data, track its path, and manage access. | Flow diagram, relevant locations, retention rules, and deletion rules. |
| Governance | Approve, monitor, and stop the workflow. | Named roles, approvals, records, and a shutdown process. |
| Operations | Keep the configuration, access, and records up to date. | Owners, instructions, and change history. |
| Dependencies | Keep a list of components and parties. | The function of each dependency and change notices. |
| Exit | Recover useful materials and close access. | Export check, return of materials, revocation, and planned deletion. |
This allocation is the record of responsibility. It produces neither a score nor a league table.
How I check the exit process before committing
I treat the exit process as one step in the pilot. The check covers data, configurations, instructions, access, and the deletion agreed in the contract.
Exit checklist
- Describe the workflow, its owner, and the expected result.
- Define permitted and prohibited data.
- Map the systems, relevant locations, and subcontractors.
- Define human review and shutdown conditions.
- Obtain the planned evidence before using real data.
- Export data and configurations in the documented formats.
- Revoke access and request the deletion agreed in the contract.
- Record the materials that the team or another supplier can take over.
I add the result that I saw to the record. If I cannot finish a step, I note it as an unverified dependency.
FAQ
Does a European company guarantee that data stays in Europe?
No. The location of its headquarters does not by itself document processing regions, backups, support access, components, or subcontractors. In my method, I request a flow diagram, the relevant locations, a list of the parties, and contractual commitments.
Does the AI Act require you to choose a European supplier?
The Commission page cited here presents the European AI Act through a risk-based approach (European Commission). It does not set out a general rule that requires choosing a European supplier (European Commission). This answer is not legal advice (European Commission).
How do you check subcontractors and dependencies?
In my method, I request a current list, the function of each party, the data concerned, the relevant locations, and the change notification procedure. I then connect each dependency to the technical diagram and the contract.
What should you prepare before changing suppliers?
I prepare the export formats, the return of configurations and instructions, the revocation of access, and the deletion agreed in the contract. I run this check within the scope of the pilot and record the result.
This record does not compare suppliers. It keeps a dated decision. That decision covers the entity engaged, the data, the dependencies, the people in charge, the evidence, and the exit process.