How to choose who to trust with digitalising your business

Trust your digitalisation to someone who wants to understand how you work before talking technology, puts the phases, timings and costs in writing, and shows you a first working piece before you fully commit. Then check three things: that code, data and access stay yours; that they can show, with documents, how they comply with the GDPR and the AI Act; and that it is clear who supports you after delivery.

Which criteria really matter?

The criteria that matter are the ones you can check, not the promises. Here are the ones that make the difference for a small or medium-sized business, and how to check them:

An example: an installation company with 20 technicians wants an app for job sheets and an AI assistant to answer customers. The right partner first asks how a job starts today, who closes it and where information gets lost. Only then do they talk about apps and AI.

A proposal in phases and a working trial are the two criteria that protect you from the most common risk: finding out, well into the project, that the result is not what you had in mind. With phases you can stop or change course after each step, paying only for what you have approved. With a trial, even a small one, you see how the partner works: how they communicate and how they handle corrections. Ask for it to use real data, or realistic examples, and to be tested by the people who will use the software every day. It is how we work too: five steps from listening to delivery, paid in approved phases. To understand how the price of each phase is made up, see the guide on how much custom business software costs.

Who will own the code, data and access?

You should, and the contract must say so. Italian copyright law gives the business, unless agreed otherwise, the economic rights to software written by its own employees as part of their job (Article 12-bis of Law 633/1941). When an outside supplier writes it, there is no such clear-cut rule: the transfer of rights and the handover of the source code must be put in writing.

Check access too, which often matters more than the code:

• the website domain and email accounts registered to your business;
• server and cloud service accounts in your name, with the partner as an authorised user;
• the code archive (the “repository”) open to you as well;
• data that can be exported in an open format, readable without the partner’s software.

That way, if you change partner, you take everything with you without having to negotiate.

How do you check compliance with the GDPR and the AI Act?

By asking for documents, not reassurance. If the partner will process personal data on your behalf (about customers, employees or suppliers), the GDPR requires you to use only someone who provides “sufficient guarantees” and to govern the relationship with a written contract: this is the data processing agreement under Article 28, which appoints them as your data processor. Ask to see a draft, together with the planned security measures (Article 32) and the list of providers they rely on: without your written authorisation they cannot hand your data to anyone else.

If the project uses AI, your business is almost always a “deployer”, meaning someone who uses an AI system under their own authority (Article 3 of the AI Act). The AI Act has been amended by the “Digital Omnibus” regulation on artificial intelligence (Regulation (EU) 2026/1744, in force since 27 July 2026), which pushed back the obligations for high-risk systems. Two practical points remain: the measures to prepare the people who use AI (Article 4) and, from 2 August 2026, the duty for a system that talks to people to make clear that it is an AI (Article 50). A good partner shows you how the project meets them and how it logs every action the AI takes, so that a person can check and stop the decisions that matter. The details are in the guide to the AI Act for SMEs and in the one on what AI agents really do.

Where is the data, and who answers when something stops working?

Your data should be in places you know, and support should come with names and times in writing. Ask which country the servers and backups are in: if personal data leaves the European Union, the GDPR sets precise conditions for the transfer (Chapter V). Ask too which security certifications there are and who holds them. ISO/IEC 27001, for example, certifies the system an organisation uses to manage information security: it is often held by the infrastructure provider, not by whoever develops the software, and you should be told so. We too work on EU infrastructure from ISO 27001-certified providers: the certification is theirs.

For support, ask them to tell you:

• who answers, through which channel and at what hours;
• how quickly they pick up a fault and how quickly they fix it, telling a total outage apart from a minor problem;
• how often backups are made and how long it takes to restore them;
• who your single point of contact is, and who stands in when they are away.

Documentation completes the picture: a manual for the people who use the software and technical documentation for whoever will develop it further, even if that is not the same partner.

Which signs deserve a closer look?

None of these signs is enough on its own to rule someone out, but each one deserves a follow-up question:

• the quote is a single figure, with no phases and no list of what is excluded;
• the solution comes before any questions about your work;
• there is no trial before the full contract;
• the domain, servers or accounts stay in the supplier’s name;
• when you ask “where is the data?”, the answer stays vague;
• precise results are promised without measuring the starting point;
• the AI “decides on its own” and nobody can tell you how to check it or stop it;
• you are asked to sign in a hurry, before you have read the contract calmly.

What should you ask at the first meeting?

Copy this list and take it with you. The answers, ideally in writing, let you compare candidates on the same basis.

1. What do you need to know about my work before proposing a solution?
2. Will you give me a written proposal divided into phases, with timings and costs for each?
3. What will I be able to use at the end of the first phase?
4. Can I see a first working piece before committing to the whole thing?
5. Will the source code, data, access and brand be mine? Where do we write that down?
6. Which country will the servers and backups be in, and with which providers?
7. Can you show me a draft data processing agreement (Article 28 GDPR)?
8. If we use AI, how are its actions logged and who approves the important decisions?
9. Who will be my single point of contact?
10. Who provides support after delivery, at what hours and with what response times?
11. What documentation will you hand over?
12. If one day I wanted to change partner, what would you hand over, and how quickly?

What should the contract say?

The contract must say who owns what, how your data is protected, what service you get after delivery and how you get out. Have a lawyer you trust read it before you sign, and look for these clauses:

• Intellectual property. The rights to the software developed for you are transferred to you, with handover of the source code and documentation. If the partner uses existing components of their own or from third parties, the contract must say under which licence you can keep using them.
• Confidentiality. A commitment not to disclose information about your business, your customers and your processes, even after the relationship ends.
• Data processing agreement (Article 28 GDPR). It must be in writing, which can be electronic. Among other things, it must require the partner to process data only on your documented instructions, bind the people who handle it to confidentiality, take appropriate security measures, bring in no other providers without your written authorisation, and allow you to carry out checks, inspections included. When the service ends, at your choice, they delete or return all personal data, unless the law requires it to be kept.
• Service levels. Response and resolution times, support hours, backup frequency, service availability, and what happens if these are not met.
• Exit and return of data. The format, timing and cost for returning all your data, not just the personal data; the handover of access; a handover period working alongside whoever takes over, if needed.

Where to start tomorrow

Start from the problem, not the supplier. Three steps are enough to get off to a good start:

1. Write one page on the problem. What does not work today, what it costs you in time or mistakes, what you would like to see in six months. No solutions: those are the partner’s job.
2. Meet at least two candidates with the same list of questions. Note who asks you more questions.
3. Ask each one for a proposal in phases and a small trial. If a trial is not possible, ask why: the answer tells you a lot about how the project will go.

If you want to put the list above to the test, bring it to our 30-minute initial assessment: write to us and we will answer every question.