Bureau theme
Rome Worked from Barcelona Built to be audited Same hour as us

Rome.
Built for procurement.

We are based in Barcelona and work with Roman organisations remotely, on the same clock. Rome is not Milan with monuments: the buyer here is usually spending public money or answering to someone who is, which means the question is rarely whether a system works. It is whether you can prove afterwards what it did and why.

Last reviewed 5 September 2026 · Engineering guidance, not legal advice.
WHAT IS ACTUALLY DIFFERENT HERE
01

Procurement is part of the design

Public bodies and the large partly-public groups around them buy through tender, and a tender fixes the shape of the thing before a line of code exists — deliverables, acceptance criteria, documentation, who owns the result, what happens to the data when it ends. We treat those as engineering constraints rather than paperwork. A system that cannot be described in those terms is one that will be rebuilt at acceptance, which is the most expensive place to discover it.
02

Evidence outlives the project

A commercial client asks whether the output was right. A public one asks who is accountable, what the system was shown, which rule it applied and whether a citizen can be told. That means logging and record-keeping are part of the specification from the first session, not observability added later. Most of what we describe under AI governance exists because of this class of buyer.
03

No Roman cloud region

This is a real difference from Milan, and worth saying plainly: the Italian cloud regions are in the north. Data stays in Italy, and that is normally the requirement, but the compute is several hundred kilometres from the building. It matters for latency-sensitive work and for anything that has to keep running when a link does not — which is why some Roman projects end up self-hosted on infrastructure the organisation already controls rather than in a public region at all.
04

The AI Act lands here first

Several of the uses that cluster in this city — administrative decisions affecting individuals, access to public services, anything touching law enforcement or critical infrastructure — sit in the parts of the EU AI Act that carry the heaviest obligations. That is not a reason to avoid the work. It is a reason to know at the outset which category you are in, because it decides how much of the budget goes to documentation and human oversight rather than to the model.
THE WORK THAT COMES OUT OF THIS CITY

The organising fact about Rome is scale of correspondence. Ministries, agencies, national utilities and telecoms operators all run enormous flows of documents between themselves and the public, and most of the useful AI work in the city is somewhere in that flow.

Public administration brings citizen-facing document processing: applications, claims, certificates, appeals. The failure mode here is specific and worth naming — a confidently wrong answer to a citizen is not a bad customer experience, it is a decision someone may act on and later contest. So these systems get built to assist a named official rather than to replace one, with the source document quotable in the response. That is the substance of our public sector work.

Energy and utilities arrive with regulatory filings, grid and asset records, and a long tail of technical documentation that engineers currently search by memory. Retrieval over that is unglamorous and it is usually the highest-value thing available.

Defence and aerospace organisations arrive with the strictest deployment constraints of anyone we speak to, and often the answer is an open-weight model running on their own hardware with no external call at all. We describe what that costs and what it gives up under on-premise AI, rather than pretending it is free.

Telecoms bring volume: support contacts in the millions, where even a small deflection rate is material and a small error rate is a regulatory problem. The engineering is in the routing and the refusal behaviour, not the fluency.

Across all four, the deliverable we are most often asked for after the system itself is the record of how it behaves over time, which is why observability tends to be in scope from the start here rather than added in year two.

HOW A ROME PROJECT ACTUALLY RUNS
01

We come down for discovery

Barcelona to Rome is a short direct flight and the first workshop belongs in a room, particularly where several departments own different parts of the same process. We do not bill it as a line item on a normal engagement. We ask for the real documents on the day, including the ones that arrive badly scanned and handwritten in the margin.
02

Then remote, same working day

Italy and Spain share an hour, so there is no overlap to manage and no morning lost to time conversion. Where an approval has to move through several layers, that matters more than it sounds — the queue is the bottleneck, not the calendar.
03

And back for handover, with the file

Handover here is two things: the session where your engineers take ownership, and the written record an auditor or an oversight body will read later — what the system does, what it was tested against, where the logs live, what the human step is. We produce that as part of the work rather than as an extra. After it, the system is yours, in your repositories and your infrastructure.
QUESTIONS
QUESTIONS — 5

No. We have one office and it is in Barcelona. We travel to Rome for discovery, for handover and for anything where being in the room changes the outcome. We have no Italian entity, no local partner firm and no representative here, and we would rather say that at the start than have it emerge during a procurement check.

Be careful with how you use us here. We are a small engineering studio without an Italian entity, so we are not a realistic prime bidder for a public tender and we will not claim otherwise. Where we are useful is as the technical supplier or subcontractor to an organisation that is bidding, or working directly with a body under a threshold or a framework it already holds. We can also write the technical sections a bid needs — architecture, data flows, evaluation approach, oversight design — which is often the part that is hardest to get right.

Yes. The Italian cloud regions are in the north rather than in Rome, which changes latency rather than jurisdiction, and open-weight models can be self-hosted on infrastructure you already control, including with no external network path. Where a hosted model is used we document its retention and training terms at the time of writing, and you should confirm them against the provider's current terms.

That depends on what the system decides and about whom, and it is worth establishing in the first week rather than the last. Broadly: the more directly an output affects a person's access to a service or a right, the more the obligations shift towards documentation, human oversight, logging and transparency. We build so those are available; your legal function owns the classification and the declaration. We are engineers, not counsel, and a page like this is not the place to be told which category you are in.

The same as anywhere else — the ranges are on the pricing page, in euros and exclusive of VAT. We do not price by postcode. Where a project carries heavy documentation and audit obligations the estimate goes up, because that is genuine work, and we would rather show it as a line than hide it in a day rate.

Keep reading
30-minute technical call · no deck

In Rome and
building something?

Thirty minutes on the problem, and an honest read on whether we are the right team for it.

CASE STUDIES

Shipped work.
Go and check it.

The work we can name, with the live site, our scope and the boundary made explicit. Select a project to see the evidence; each is a full case study, not a logo or a claim.

sonora.com
The Sonora homepage on desktop: a full-bleed dune landscape behind the headline “Transform Your Life with Sound”, with App Store and Google Play download buttons.
sonora.com — homepage, 1440×900 sonora.com →
Live Consumer wellness · Mobile + web

Sonora

Cognitive AI Ltd · 2026

A free sound-wellness app, described by its publisher as AI sound therapy that reads a short vocal sample at the start of a session and generates a soundscape for that moment. We designed and built the website and its backend, produced assets for the iOS and Android apps, and supported the application prototype.

Read the case study →

See every published project →

WHO WE HAVE BUILT FOR

Twenty-one years of applications, platforms and campaigns for names you know.

See all of our work →