Ten decisions to take before AI goes into production. This is not a certification and not legal advice: it is the outline we use ourselves when an AI project moves from a trial to a service.
This guide is written for the people who have to decide: management, IT, security, compliance, HR and operations in SMEs, industry, public bodies and supply chains. You can read all of it here, with no registration and no form.
Why this guide
AI is entering business processes: document search, document management, assistance, analytics, quality control, maintenance, automation. Value does not depend only on which model you pick. It depends on the ability to design a system that works in the organisation’s real context, with adequate data, clear responsibilities and proportionate controls.
The ten decisions below are not a compliance exercise. They are the questions that, when they have no written answer, all come back at once on the day something goes wrong.
1. Which problem are we trying to solve?
Starting from technology almost always produces generic projects; starting from a process produces a reviewable decision. Define the activity to improve, the users, the expected outcome and above all what must not change: service quality, safety, human accountability.
Key question: which decision or activity will be better because of AI?
2. Which data do we actually need?
Map input data, sources, owners, quality, update cycles and permissions. Apply minimisation: unnecessary data adds complexity, risk and cost, and does not add accuracy. Where real data is confidential or insufficient, assess synthetic data or a different scope — without assuming it is risk-free, because re-identification remains something to evaluate case by case.
Key question: can we explain why each data category is necessary?
3. Who owns the project, the data and the decisions?
An AI system involves business, IT, security, privacy, legal and end users. Appoint a process owner and define who approves data and suppliers, who reviews outputs, who handles incidents and changes. If that list is empty, the de facto owner will be the last person who pressed send.
Key question: if an output is wrong, who can stop it, correct it and communicate about it?
4. Where is human oversight needed?
AI can assist, recommend or automate. The greater the impact on people, customers, security or continuity, the more meaningful human control has to be. And oversight does not mean being able to click “approve”: it means the person approving has the information, the time and the competence to say no.
Key question: does the reviewer have the information, capability and real authority to intervene?
5. How do we review quality and limitations?
Define test cases, thresholds, acceptable errors, comparison sources and paths for uncertain outputs. For generative systems, assess factual grounding, citations, tone, coverage and out-of-scope behaviour. For computer vision and predictive models, assess whether the data is representative and whether real operating conditions resemble the ones used in testing — they rarely do.
Key question: how do we know when not to rely on the system?
6. How do we protect data, secrets and access?
Design roles, permissions, segregation, credential management, input protection, proportionate logging and escalation channels. Do not treat a prompt as a protected environment by default. And check what happens afterwards: to the documents uploaded, the outputs produced, the logs retained.
Key question: which information must never enter the system?
7. How do we make the system transparent?
Explain to users and affected people, where required or simply appropriate, that they are interacting with AI, what the system is for, what its limits are and how to reach human support. Assess the AI Act transparency obligations for your role and your scenario, particularly for systems that interact with people or that generate and manipulate content.
Key question: does a person know what they are using, and how to challenge or correct a result?
8. How do we select and govern suppliers?
An AI supplier is part of the architecture, not a purchase. Assess contractual terms, privacy roles, sub-processors, location, access, configurations, incident management, data export and deletion, and support for documentation. A supplier’s name is not a guarantee: terms change, and they need re-checking.
Key question: do we have current evidence of how the supplier processes data and runs the service?
9. How do we manage the lifecycle?
Models, documents, prompts, data and integrations change. Define how a system is released, monitored, updated, tested and retired. This is the work that LLMOps and AI Engineering turn into an operational discipline, with metrics, reviews and assigned ownership. A system nobody measures does not degrade less: it degrades unseen.
Key question: what happens after go-live, and how do we detect degradation?
10. Which evidence do we need to keep?
Inventories, decisions, instructions, assessments, tests, proportionate logs, training and incidents are what let you govern a system and hold a conversation with auditors, customers and control functions. Keep what is useful and lawful: more data does not automatically mean more accountability, and a pointless archive is still a risk you have to look after.
Key question: can we document how and why the system is used?
The matrix: use, risk, control, evidence
| Area | Question | Control | Evidence |
|---|---|---|---|
| Purpose | Which process does it support? | Approved owner and scope | Use-case record |
| Data | Which data does it use? | Minimisation, access and quality | Data inventory and permissions |
| Output | How is it reviewed? | Testing, thresholds and human-in-the-loop | Test report and procedures |
| People | Can it affect rights or decisions? | Oversight and a review channel | Operating instructions |
| Security | Which attacks or exposures matter? | Permissions, guardrails, escalation | Risk assessment and approved configurations |
| Suppliers | Who runs the critical components? | Due diligence and contractual terms | Supplier register and agreements |
| Lifecycle | How is it updated? | Change management and monitoring | Version register and alerts |
| Transparency | Who must be informed? | Notice, labelling or support | Approved copy and records |
Project-start checklist
Ten lines. If one stays unticked the project can still start — but you know where the weak point will be.
- The use case has a business owner and a clear operational objective.
- Data, sources, quality and permissions are mapped.
- Roles are defined for business, IT, security, privacy/legal and users.
- Human review is proportionate to the consequences of the output.
- Tests cover normal cases, boundaries, errors and expected failures.
- Secrets, personal data, access, suppliers and logs have been assessed.
- Users receive instructions on limitations, correct use and reporting.
- Transparency duties and other applicable requirements have been assessed.
- The system has a plan for monitoring, updating and retirement.
- Relevant decisions and evidence are documented.
What this means for the AI Act and the GDPR
The AI Act introduces a risk-based framework and places different obligations on providers, deployers and other actors. From 2 August 2026 the Regulation applies in general, including the Article 50 transparency obligations where the conditions for them are met. For high-risk systems the main application dates were deferred by Regulation (EU) 2026/1744 to 2 December 2027 for the Annex III categories and 2 August 2028 for systems embedded in products covered by EU harmonisation legislation.
The GDPR continues to apply where a project processes personal data: legal bases, privacy notices, minimisation, privacy by design, security and, where the conditions are met, impact assessments all remain central. AI Act roles do not automatically match GDPR roles: provider and deployer are not controller and processor, and confusing the two is a common mistake.
The full application dates and primary sources are on Transparency and the AI Act.
How we can support you
Infordata works on AI Engineering and governance programmes that combine discovery, integration with existing systems, knowledge bases, LLMOps, security, computer vision, sensor data and monitoring. We work with the customer’s own functions to turn a use case into a system that is designed, validated and manageable over time.
How we work on an AI project →
Sources
- Regulation (EU) 2024/1689 (AI Act), consolidated text.
- Regulation (EU) 2026/1744, amendments to the application timetable.
- Regulation (EU) 2016/679 (GDPR).
- Italian Law no. 132 of 23 September 2025 on artificial intelligence.
- European Commission, guidelines on transparency obligations and AI literacy Q&A.
⚠️ Notice. Information current as of 22 August 2026, version 1.0. This material does not constitute legal advice. Applicable obligations depend on role, system, data, context and sectoral rules. The text may be cited with attribution.