Implementing AI projects with the legal framework built in from day one

We start with the process, not the tool

Most failed AI projects began the other way round: someone bought a licence and then looked for somewhere to use it. We identify where there is repetitive volume, where errors are expensive and where automation genuinely helps, and we discard without ceremony the use cases whose legal risk outweighs the operational benefit. Saying no to a use case is part of the job, and it is usually the part that saves the most money.

Designing the delegation of tasks

The central question in an AI project is not technical: it is how much is delegated and what stays in human hands. We answer it task by task and put it in writing.

• What the system does, what the person does and exactly where the human control point sits.
• An acceptance criterion for each deliverable: what counts as correct and who says so.
• The reviewer, by name and role, not by the name of a department.
• The evidence kept for each decision, for the day it has to be reconstructed.
• What happens when the system fails or produces an output that does not pass review.

What has to be resolved before connecting the data

This is where most projects get sent back, almost always once the investment is made and a date has been committed. It gets reviewed first.

• Purpose. Whether the data the system will use was collected for this or for something else, and what has to be done if it was for something else, under Law 1581 of 2012.
• Authorisations and privacy notice. Whether they describe the use the project will make and what adjustment they need.
• Third party information. Data and documents the company received from clients or suppliers under confidentiality agreements that do not contemplate this use.
• Intellectual property and trade secrets. The origin of input content, ownership of outputs and what proprietary information cannot leave towards the system, under Law 23 of 1982 and Andean Decision 351 of 1993.
• Consumers. If the system will interact with end customers, what it may promise and what ends up binding the company.

Contracting and go-live

We structure the relationship with the vendor —scope, data, intellectual property, confidentiality, service levels, liability, audit and termination— and, where the project touches the end client, we review that contract too so both ends say the same thing. In parallel we leave ready the internal use policy, the incident protocol and the training of the people who will run the process, which is where it is decided whether the design gets applied or abandoned in the first week. We also agree who signs off on go-live and on what basis, so that the decision to switch the process on is a documented one and not the by-product of a deadline.

Monitoring and updating

An AI project does not end on go-live day. Vendor terms change often and without notice, models are updated, and teams start using the system for things nobody anticipated. We periodically review the inventory, the incidents, the vendor's contractual changes and the evolution of regulation, and adjust what needs adjusting before it turns into a finding.

What the client receives

• The use case diagnosis, with those prioritised and those discarded, and the reason for each decision.
• The task delegation map, with human control points, owners and acceptance criteria.
• The personal data documents adjusted to the project: authorisations, privacy notice and processing policy.
• The negotiated vendor contract and, where applicable, the amendment to the end client contract.
• The internal use policy, the incident protocol and training for the teams running the process.
• A periodic review plan, setting out what has to be looked at again and how often.