How to choose an AI implementation partner: a 20-question checklist and key contract clauses (EU AI Act, GDPR, IP, acceptance criteria)

The difference between an AI implementation that delivers measurable impact and a project that ends at the slide deck stage rarely lies in the technology. It lies in how your partner handles data, how they measure outcomes, and what you sign in the contract. This text is a list of questions for your first meetings with a vendor and the clauses that should be in the contract before the project starts.

This is not legal advice; have a lawyer review contract terms, especially for high-risk systems under the AI Act.

Key takeaways

• Start with the problem, not the model. A good partner first asks about the process, data, and desired outcome—then about the tech stack.
• Data determines the outcome. Ask about a data audit, access, permissions, and where data will be processed.
• An AI contract is not a standard software contract. It must cover AI Act roles, GDPR data processing, ownership of code, prompts, configurations and model weights, acceptance criteria based on metrics, and model usage costs.
• Acceptance is about statistics, not a button. Define acceptance on a test set, with quality thresholds, response time, and per‑query cost.
• Plan the exit. Documentation, handover, and model interchangeability protect your company after the partnership ends.

What an AI implementation looks like in a company

An AI implementation is the design and launch of a system that uses machine learning models or large language models (LLMs) in your business processes: an assistant for employees or customers, an agent that performs tasks in systems, a RAG knowledge base, a predictive model. In most business projects you don’t train models from scratch; you use off‑the‑shelf models via API or open‑weight models and connect them to company data and systems. That’s why a partner’s strengths should be integration, data, security, and measuring impact.

Three pillars for vetting a partner

Technology and data

Before you ask about price, check how the company works with data: do they audit sources, clean and structure data, carry over permissions from source systems into AI, choose models based on cost, quality, and processing location, and can they swap the model without a rebuild? A partner who immediately proposes training a custom model should be able to prove why an off‑the‑shelf model with RAG isn’t enough.

Business and measurement

Implementations without a discovery phase (what we measure, current baseline, how we define success) end up as unused features. A good partner proposes a pilot on one process and real data, measuring before and after.

Legal and security

The AI Act is phased in from 2024 (prohibitions and AI literacy obligations from February 2025, transparency from August 2026, high‑risk systems from December 2027). GDPR applies in full. The partner should know their role (provider or deployer under the AI Act; processor under GDPR) and what that implies for the contract.

Red flags and best practices

Checklist: 20 questions to ask an AI implementation partner

Experience

1. Can you show a production AI system with numbers? Look for case studies with metrics (time, cost, revenue), not descriptions.
2. What problems came up in previous implementations and how did you solve them? The answer shows whether the partner surfaces risks before they happen.
3. Do you have experience in our industry? Data in fintech, healthcare, or manufacturing come with different security and compliance needs.
4. Have you taken over systems from other vendors and integrated AI with legacy systems? Most companies don’t build from scratch.

Data and architecture

1. What does your pre‑implementation data audit look like? Sources, quality, gaps, permissions.
2. How do you choose the model, and can your architecture swap it out? A question about single‑vendor lock‑in.
3. How do you reduce hallucinations? RAG on verified sources, source citations, answer‑quality tests, refusal to answer when data is missing.
4. How do you carry over permissions from source systems into AI? Users should only see what they’re entitled to.
5. How do you test a system with nondeterministic answers? Test set, metrics, regression tests after every model or prompt change.
6. Who monitors quality after go‑live, and how? Logs, metrics, alerts, plan for retraining or model replacement.

Security and legal

1. Where will our data be physically processed and by which entities? Model vendor’s cloud, client’s cloud, client infrastructure; list of sub‑processors.
2. Can company data be used to train the provider’s models? Expected answer: no, based on a business agreement with the model provider.
3. How do you ensure GDPR compliance? Data processing agreement, data minimization, DPIA if required, right to erasure.
4. What will your role be under the AI Act and what will ours be? Provider or deployer; risk category; documentation and oversight implications.
5. What safeguards do you apply to data in prompts and responses? Sensitive‑data filters, logging, access control, security testing (including prompt injection).

Collaboration and costs

1. How do you define a pilot and what will it deliver? Scope, data, metrics, scale‑up decision.
2. How do you break down pricing? Build, model usage (at estimated query volumes), maintenance and evolution. A single lump sum is a red flag.
3. Which business metrics will we track? Time saved, cost to serve, conversion, revenue; measured before and after.
4. Who exactly will work on the project and in what model? Dedicated team, extension of our team, fixed‑scope project; access to an architect.
5. What do we get at the end and how is handover handled? Code, documentation, prompts, configurations, test and evaluation sets; ability for another team to run it.

Contract elements for an AI implementation

1. Roles and responsibilities under the AI Act

• Define who is the provider (develops and places on the market) and who is the deployer (uses it in their operations). If the system is built to order under the client’s brand, the client may be the provider; the contract should state this explicitly.
• Risk classification of the system in the contract or annex; for high risk: who is responsible for technical documentation, logging, human oversight, and conformity assessment.
• Transparency: the system informs users that they’re interacting with AI; generated content is labeled, in line with Art. 50.
• AI literacy (Art. 4): training the client’s team as part of delivery, not a nice‑to‑have.
• Incident reporting: procedure and timelines for informing the client about system errors and security incidents.

2. GDPR and data

• Data processing agreement (Art. 28 GDPR) with the partner and a list of sub‑processors (including model providers), with the right to object to changes.
• Processing locations and regions (EU/EEA), rules for transfers outside the EEA.
• Ban on training the provider’s models on the client’s data, backed by a business agreement with the model provider.
• Data minimization and anonymization before sending data to the model; sensitive‑data filters.
• Data deletion: architecture (RAG instead of training on personal data) must allow erasure of a person’s data without retraining the model; log retention (for high‑risk systems at least 6 months under the AI Act).
• DPIA and, for certain deployers at high risk, a fundamental rights impact assessment (Art. 27 AI Act): who prepares it.

3. Intellectual property

• Assignment (not just a license) of IP rights to code, data scripts, documentation, prompts, configurations, test and evaluation sets, across all uses, effective upon payment for each milestone.
• Model weights: if the partner fine‑tunes a model, rights to the weights and training data pass to the client to the extent allowed by the base model’s license. You can’t “buy” third‑party provider models (OpenAI, Anthropic, Google); the contract should clearly distinguish this.
• Open‑source components and open‑weight models: a bill of materials with licenses and confirmation of compliance for commercial use.
• AI‑generated content: copyright protects human authorship; the contract should set rights to outputs and responsibility for their use, without promising protection the law doesn’t provide.
• Partner’s know‑how: if the partner brings proprietary components or products (e.g., a ready‑made knowledge base), a license to them with the right to continue use after termination.

4. Acceptance criteria

• An agreed test set before kick‑off (representative queries and expected answers), used for acceptance.
• Task‑appropriate quality thresholds: for a knowledge‑base assistant, e.g., percentage of correct, source‑grounded answers and refusal rate when data is missing; for classification: precision and recall; for extraction: field‑level accuracy.
• Response time (e.g., 95th percentile) and per‑query cost at the assumed volume.
• Security: tests for prompt injection and data leakage, permission checks.
• Human oversight: where a human approves the result before it reaches a customer or system.
• Realism: AI has an error margin; acceptance defines an acceptable level, not 100%.

5. Costs, maintenance, and exit

• Pricing broken down into build, model usage (with a pass‑through mechanism for provider price changes), and maintenance.
• SLA for availability and response times; quality monitoring as a service, not just a promise.
• Model interchangeability as an architectural requirement written into the contract.
• Exit clause: handover of code, documentation, data, and configurations in an agreed format, transition period, support for the next team.
• Confidentiality and audit: the client’s right to audit security and compliance at the partner and sub‑processors.

What type of partner to look for

It depends on your starting point: one partner fits adding AI to existing systems (an AI‑focused software house), another fits a corporate transformation program (a large systems integrator), another fits data cleanup and structuring (an analytics firm). You’ll find a list of AI implementation firms in Poland by partner type in our ranking of the TOP 10 AI implementation companies in Poland.

Startup House builds AI assistants, agents, and RAG knowledge bases for mid‑market and enterprise, including regulated industries (fintech, healthcare, cybersecurity). Solutions run on the client’s verified data, in the client’s cloud, integrated with access policies; client data does not train public models. ISO 27001‑compliant. Example: a customer portal with built‑in AI for a cybersecurity platform serving Fortune 500 clients cut onboarding by 95%, and taking over and modernizing a logistics system for Omnipack reduced development costs by 40%.

See also: AI Act: what a company implementing AI must do · Startup House case studies

FAQ

In‑house AI team or a software house?

Hiring an AI team takes months, and your first implementation needs integration and security experience. For most companies, the model that works is: start with a partner, build internal capability in parallel (training, an internal product owner), and gradually take over maintenance.

How much does an AI implementation cost?

It depends on scope. A pilot assistant for one process using off‑the‑shelf models is a project of a few weeks; a multi‑department rollout with integrations takes months. Pricing should separate build, model usage, and maintenance.

Does the AI Act make implementations harder?

For most business implementations (minimal risk), obligations boil down to employee AI literacy and user transparency. High‑risk systems (recruitment, credit scoring, biometrics) require documentation, logging, and human oversight, with the deadline starting in December 2027. A partner who understands this designs the system to meet requirements from day one.

What are the biggest risks in an AI implementation?

Poor‑quality data, no baseline measurement, lack of team buy‑in, lock‑in to a single model provider, and a contract that doesn’t define ownership of code, prompts, and data.

How long does implementation take?

A pilot on one process and real data can be built in a few weeks. A production rollout with integrations and security takes longer and depends on the number of systems and data quality.

Can I change the model provider during or after the project?

Yes—if the architecture anticipates it and the contract requires it. Models change every few months; a system where the model is a swappable component won’t need a rebuild when you switch providers.

Where should a company start to prepare for an AI rollout?

Begin by analyzing business processes, available data, and employee needs. Then choose areas where AI tools can deliver tangible benefits and appoint a project owner. Next steps should include risk assessment, a pilot in a controlled environment, and gradually expanding use in day‑to‑day work.

What is an AI policy and should every company have one?

An AI policy is an internal document that sets rules for using AI systems in the organization. It should specify approved AI tools, restrictions on data input, verification rules for outputs, and responsibilities of employees and administrators. It can also cover how to select vendors, update AI models, and report incidents. A well‑designed AI policy supports legal compliance and safe adoption.

Is an AI systems register mandatory in every organization?

Not every organization must keep a formal register of all AI systems. However, an internal register is good risk management. It should include the system’s name, purpose, vendor, data used, risk category, and responsible owner. For certain high‑risk systems, the EU AI Act also provides registration obligations; scope depends on the organization’s role and the system’s use.

How do you run a risk assessment before implementing an AI system?

Start by defining the system’s purpose, the data it will process, and the potential impact on individuals and the organization. The analysis should cover information security, AI output quality, erroneous decisions, human oversight, and any prohibited practices. Also determine whether the use case could be classified as unacceptable risk or high‑risk under the AI Act. Risk assessment isn’t a one‑off—update it as the system changes.

Does an AI implementation require a Data Protection Impact Assessment?

A Data Protection Impact Assessment (DPIA) is required under GDPR when a given type of processing is likely to result in a high risk to the rights and freedoms of individuals, particularly for certain profiling and automated decision‑making uses. Using AI alone doesn’t automatically trigger a DPIA. A DPIA doesn’t replace the AI Act’s risk analysis—each mechanism addresses partly different risks.

What does AI literacy mean and what training should employees take?

AI literacy means the competencies to use AI systems consciously, safely, and responsibly. Training should cover model capabilities and limits, personal data protection, output verification, and error recognition. Materials should be tailored to employee roles and how AI tools are used day‑to‑day. Art. 4 of the AI Act provides for actions to ensure appropriate AI literacy by providers and deployers.

Who is a provider and who is a deployer under the AI Act?

A provider develops an AI system or has it developed and places it on the market or puts it into service under their own name or trademark. A deployer uses an AI system in the course of their activities, other than for personal, non‑professional use. This role split matters for documentation, oversight, security, and EU law obligations. In certain situations, the organization implementing the solution may take on provider obligations.

How does human oversight of AI work—human in the loop?

Human in the loop is a model where a person participates in reviewing or approving AI results. They can check recommendations, correct errors, and make final decisions in situations that need extra control. This is especially important when automating processes that affect customers, employees, or individuals. Oversight must be real: the person needs to understand system limits, be able to challenge outputs, and have the authority to intervene.

This text is for information only and is not legal advice. Legal status: October 2026 (AI Act after the Digital Omnibus, Regulation 2026/1744).