Legal Tech Analyst in AI projects: compliance by design and Law 132

TL;DR

Law 132/2025 does not force companies to have a "legal tech analyst" on the team. But it makes one point much clearer: in artificial intelligence projects, compliance cannot be a final check.

If the legal side enters when the process is already designed, the dataset chosen, the vendor selected and the automation almost ready, it is often too late. At that point compliance does not help you design better: it becomes a brake, a costly review, or in the worst cases a full rework.

The new paradigm is different: putting technical skills and legal tech skills in the same team from the assessment phase.

In practice this means:

mapping processes, data and AI tools before choosing the solution;
understanding immediately whether the use case touches privacy, employment, customers, HR, credit, security or automated decisions;
translating the business process into concrete risks, obligations and safeguards;
designing architecture, human oversight, traceability and documentation together with the technical solution;
reducing the risk of discovering too late that an AI project must be changed, limited or stopped.

We are already working this way: technical assessment and legal tech reading in the same journey. Not to bureaucratize AI, but to make it implementable without surprises.

The Problem: We Design AI As If It Were Normal Software

Many companies are approaching artificial intelligence with the same pattern used for a normal software project.

You gather requirements. You design the process. You pick the tool. You develop. You test. Then, towards the end, someone asks: "But from a compliance point of view, are we fine?".

With AI, this approach is fragile.

An AI project is not just a new application. It often reaches into company data, confidential documents, operating procedures, customer interactions, recruitment, decision support, content generation, automations on the CRM or internal systems.

So the questions are not only technical:

which data is used?
where does it come from?
who can see it?
does the model make decisions or support a person?
does the customer know they are interacting with an AI system?
does the employee know which tools they are allowed to use?
who checks the output?
what happens if the AI is wrong?
what evidence remains available to the company?

If these questions only surface at the end, the risk is creating rework.

And rework in AI projects costs more than usual, because it does not concern only code or configurations. It may require changing data, redesigning workflows, updating privacy notices, revising internal roles, replacing vendors, introducing human oversight or limiting features already promised to users.

Compliance, when it arrives late, looks like an obstacle.

When it arrives early, it becomes architecture.

Why Law 132 Changes the Italian Context

Law no. 132 of 23 September 2025, published in the Official Gazette on 25 September 2025 and in force since 10 October 2025, creates Italy's national framework on artificial intelligence.

The key point, for companies, is not to read it as a list of isolated requirements. The law coordinates with EU Regulation 2024/1689, the AI Act, and brings a clear direction to Italy: AI must be adopted in a correct, transparent, responsible, safe way and consistent with fundamental rights.

This does not mean every SME has to build an internal legal department dedicated to AI.

But it does mean it is no longer enough to say: "We bought Copilot", "we connected ChatGPT to the CRM", "we built an agent with n8n", "we put a chatbot on the website".

The question becomes: how did you design that use of AI?

Did you map the data? Did you separate internal use from customer-facing use? Did you define who supervises? Did you train whoever uses the system? Did you understand whether the use case might fall into a high-risk area? Did you collect minimal evidence of the journey?

The AI Act Service Desk recalls that obligations apply progressively: some provisions, such as AI literacy and prohibited practices, are already applicable from 2 February 2025; others, such as transparency and most of the application framework, mature in later phases.

The operational message is simple: waiting until the end of the project to raise the compliance question is no longer an efficient way to work.

The Traditional Team Is No Longer Enough

In a classic digital project, the minimum team is often made of:

a business analyst;
a solution architect or technical architect;
a developer or automation specialist;
a project manager;
possibly a data specialist, a security specialist or a systems engineer.

This team can be highly competent, but in AI projects it risks having a blind spot: it translates the business need into a technical solution well, but it does not always translate the process into regulatory implications, responsibilities and compliance safeguards.

This is where the new role comes in.

I am not talking about the lawyer called at the end of the project to "stamp it". And I am not talking about the engineer who improvises as a legal expert after reading two checklists.

I am talking about a hybrid role: a legal tech analyst.

A person with legal and compliance skills, but tech-literate enough to understand processes, data, integrations, automations, models, APIs, decision logic and control points.

They do not have to write code.

They have to understand the project well enough to ask the right questions while those questions still matter.

The new compliance-by-design AI team

What the Legal Tech Analyst Actually Does

The legal tech analyst does not replace the lawyer, the DPO, the security specialist or the architect. They work with them.

Their value lies in translation.

They translate the business process into risks. They translate risk into requirements. They translate requirements into design constraints. They translate constraints into operational choices that are clear to engineers and managers alike.

In an AI assessment, this role helps answer questions that often remain implicit.

Area	Key question	Why it matters
Process	Where does AI enter the real workflow?	To understand whether AI supports, automates or influences a decision.
Data	Which data does the system use?	To assess privacy, confidentiality, quality, minimization and access.
Users	Who uses or is affected by the AI output?	To separate internal use from use towards customers, workers or third parties.
Risk	Does the use case touch sensitive areas?	To avoid treating a more delicate case as simple automation.
Oversight	Who checks the output and by which criteria?	To avoid vague responsibilities offloaded onto the tool.
Evidence	What stays documented?	To prove the company designed, trained and controlled with method.

These are not questions to ask once the project is finished.

They are questions to ask before choosing the architecture.

Compliance by Design: Less Rework, More Value

The concept is not entirely new. In the privacy world, people have talked about privacy by design for years. In security, about security by design. AI projects need the same mental shift: AI compliance by design.

It does not mean weighing down every project with bureaucracy.

It means placing the compliance reading at the point where it costs the least: at the start.

During the assessment, the technical team understands:

the systems involved;
the available data;
the possible integrations;
the levels of automation;
the infrastructure constraints;
costs and timelines.

In parallel, the legal tech analyst helps understand:

which data should not enter the system;
which uses require explicit human oversight;
which outputs must be tracked;
when users, customers or employees must be informed;
which internal policies need updating;
which use cases should be postponed or redesigned.

The result is not a slower project.

The result is a project that starts with fewer weak assumptions.

And in SMEs this makes an enormous difference, because there is often no budget to redo the same thing three times. A setup mistake does not just translate into lost days: it can burn internal trust, block management, make AI feel risky and stop even the good use cases.

A Simple Example: Internal Chatbot on Company Documents

Take a common case: an SME wants to build an internal chatbot that answers questions about procedures, documents, manuals, offers, policies and the knowledge base.

From a technical point of view it looks straightforward:

collect documents;
index the content;
build a RAG system;
connect a chat interface;
let employees use the system.

But the legal tech part raises questions that change the project.

Can all documents be indexed? Are there contracts with confidential clauses? Is there personal data of customers or employees? Can chatbot answers be copied into external communications? Who sees what? Does the system separate sales, administration, HR and management? Are query logs kept? For how long? Who can access them? Do employees know what use is allowed?

If these questions arrive later, you have to rework permissions, datasets, interface, policies and training.

If they arrive earlier, the project naturally takes shape:

you separate documents by sensitivity level;
you define roles and access;
you exclude unnecessary data;
you clarify what the chatbot can and cannot do;
you prepare usage instructions for the teams;
you design logs and retention with criteria;
you avoid turning a useful tool into formalized shadow AI.

The technology stays the same.

The project becomes more solid.

Why It Also Applies to SMEs

Someone might think this approach only serves medium and large companies.

In my view it is the opposite.

Large companies have legal departments, security, DPOs, procurement, compliance and internal audit. They can afford delays, redundancies and multiple reviews.

SMEs cannot.

An SME often decides quickly, implements with small teams, uses ready-made tools, connects automations with n8n, Make, Zapier, the CRM, Google Workspace, Microsoft 365, WhatsApp Business, chatbots and generative tools.

This makes it fast.

But it also makes it more exposed to setup mistakes.

You do not need an "AI committee" for every decision. You need a proportionate method.

For an SME, the legal tech analyst can be involved in a light but targeted way at the key stages:

before choosing the use case;
during data mapping;
when deciding whether to automate or only assist a person;
before putting AI in front of customers, candidates, employees or vendors;
when activating AI tools inside already regulated processes.

Compliance should not slow SMEs down. It should prevent them from accelerating in the wrong direction.

The Point Is Not "Do Less AI"

This is the most important part.

Adding a legal tech role to AI projects does not mean slowing innovation. It means making it more implementable.

The problem for many companies is not that they do too much AI. It is that they do it in a fragmented way:

one department experiments with a tool;
another buys licenses;
someone automates a flow;
someone copies data into a chatbot;
someone builds operational prompts;
no one has a complete map.

Then, when the compliance topic arrives, the reaction is defensive: "So we cannot do anything".

That is not true.

You can do a lot. But you have to make distinctions.

There are low-risk use cases, perfect to start with. There are use cases that require policy and training. There are cases that require stronger oversight. There are cases to postpone until there are adequate data, governance or roles.

The legal tech analyst helps make this distinction.

They do not block everything. They avoid treating everything the same way.

How We Work

In the AI projects we run, we are already bringing this approach: technical skill and legal tech skill in the same analysis phase.

The starting point is not the tool.

The starting point is the process.

First we understand what the company does today, where it loses time, where the risks are, which data circulates, which tools are already used and which decisions are made. Then we assess where AI can enter with real value.

In this phase, the legal tech contribution allows for a better reading of the context:

not only "can this be automated?";
but also "can this be automated sustainably?";
not only "how much time does it save?";
but also "what responsibility stays with the people?";
not only "which model do we use?";
but also "which data and which evidence do we have to manage?".

This approach gives value to the client twice.

The first time because it avoids AI projects disconnected from real processes.

The second because it reduces the risk of having to fix downstream choices that could have been set up better at the start.

It is not an absolute guarantee. No serious assessment should promise one.

But it is a more mature way to design AI in Europe, where innovation, data, employment, privacy, responsibility and compliance are becoming parts of the same problem.

The New Question to Ask Before an AI Project

Until yesterday the question was:

Which AI tool can we use to automate this process?

Today the better question is:

Which team do we need to design this AI process without creating technical, organizational and compliance debt?

The difference seems subtle, but it changes everything.

In the first case you start from the tool.

In the second you start from the company.

And when you start from the company, you realize a well-built AI project is not just model, prompt, API or automation. It is a combination of process, data, people, responsibility, architecture and rules.

The team has to reflect this reality.

This is why I believe the legal tech analyst will become an increasingly normal role in AI projects, especially in Europe. Not necessarily as a fixed internal role in every company, but as a skill to involve at the decisive moments.

Those who integrate it early design better.

Those who ignore it risk discovering too late that the problem was not making AI work.

It was making it work inside a real company.

Checklist: When You Need a Legal Tech Reading

If you are evaluating an AI project, these questions are enough to understand whether the topic should be addressed right away.

Involve legal tech skills if the project:

uses personal data, customer data, employee data or confidential documents;
enters HR, recruiting, performance evaluation or training processes;
produces output used in offers, contracts, reports, commercial decisions or external communications;
automates parts of customer service, credit, onboarding, complaints or support;
connects to the CRM, ERP, ticketing, email, document management or internal systems;
exposes AI to customers, candidates, vendors or end users;
requires logs, traceability, audit or explanation of decisions;
is introduced into the company without a clear AI policy.

If you answered "yes" to even two or three points, it does not mean the project is risky.

It means it should be designed with method.

Frequently Asked Questions

Does Law 132/2025 require having a legal tech analyst?

No. Law 132/2025 does not create this role and does not require companies to add it to their teams. The point is organizational: the Italian AI framework, together with the AI Act, makes it more important to design AI systems with attention to data, responsibility, transparency, security and rights. The legal tech analyst is a practical answer to this need.

What is the difference between a lawyer, a DPO and a legal tech analyst?

The lawyer oversees the legal reading and the legal opinion. The DPO oversees the protection of personal data when required or appointed. The legal tech analyst works inside the project: they listen to the processes, understand the technology well enough, translate risks and obligations into operational requirements, and help the technical team avoid discovering predictable constraints too late.

Is it needed even if I only use ChatGPT, Copilot or Gemini?

It depends on the use. If a person uses an AI tool for generic drafts with no sensitive data, the risk is different. But if AI enters customer documents, company data, HR, offers, the CRM, reports or automations, you need at least a mapping and a policy. The problem is not the name of the tool. It is the process you put it into.

Does the legal tech analyst slow the project down?

If they come in at the end, yes. If they come in at the start, they usually reduce friction and rework. Their job is not to say "no" to everything, but to help the team distinguish what can be done right away, what requires safeguards and what should be redesigned.

Does this approach only apply to large companies?

No. Large companies have more internal structures, but also more bureaucracy. SMEs have less room for error: if they get the setup wrong, they risk losing time, budget and internal trust. This is why a light but well-done technical-legal assessment can carry a lot of value.

What is the first concrete step?

The first step is to map the AI already in use: tools, departments, data, purposes, people involved and outputs produced. From there you can understand which cases are low-risk, which require training and policy, and which deserve a deeper evaluation before investing.

Where to Start

If you are evaluating an AI project, do not start from the question "which tool do we buy?".

Start from a more useful question: which processes do we want to improve, with which data, with which people, with which responsibilities and with which safeguards?

A well-done AI assessment should give you two answers together:

where AI can create measurable value;
where you have to put rules, oversight and documentation so that value does not turn into risk.

If you want to set up an AI project with this technical-legal approach from the start, you can begin with an operational conversation.

Book a free call

After Law 132, AI Projects Need a Legal Tech Analyst