AI
Artificial intelligence came into my work from two directions, as technology to take into production inside a product, with real clients and real costs, and as an everyday tool that has changed the way I develop and manage systems. They are two distinct experiences, and the first teaches things the second alone cannot.
AI in production
The proving ground is AboutMyHotel, the reputation intelligence platform for hotels of which I am founder and sole developer. At the heart of the system is a layer of analysis based on language models that reads the text of reviews and produces sentiment, recurring themes, suggested actions, draft replies and a weekly briefing. The work is distributed across four agents with distinct roles, (reputation analysis, support, administration, marketing) designed as personas configurable from a panel, not as prompts fixed in the code. Each has a role, an assigned model and its own knowledge base.
Using a language model in a prototype and using it in a product in production are two different trades.
In production every call has a cost, and the cost becomes a design constraint, not a detail to optimise later. The architectural choices follow from that, model routing based on the task, with a more capable model for the narrative generation of reports and a lighter, cheaper one for structured extraction and translations; incremental data collection, because the cost of analysis is proportional to the volume processed; a pipeline of decoupled steps, which lets the analysis run on different schedules from the collection and isolates the costs per stage.
The other front is reliability. A language model is not deterministic, but the product that uses it has to be deterministic enough to reach a client, so the output is validated before it is delivered, not after. And data isolation is an architectural rule, not a good intention, and no analysis can read data from a property other than the one requested.
Transparency obligations and data protection
An AI system that interacts with people has precise transparency obligations, set out in article 50 of the AI Act. The interesting work was the mapping, finding every point where a user comes into contact with AI generated output and implementing an explicit disclosure at each one. The surface is wider than it seems, because it does not stop at the chat interface, it includes the report PDFs, the emails, the ticket replies and the legal pages of the site.
On the data side, the setup I designed and implemented starts from concrete choices, hosting and databases in the European Union, measurement tags fired only on a consent event, formal data processing agreements with suppliers, encrypted off site backups. With one more consideration, reviews are content written by third parties that passes through a language model, so the question is not only the protection of the client data, but also the handling of other people content.
Everyday tools
Outside AboutMyHotel, AI is part of my everyday workflow, assisted development of themes and plugins, log analysis, diagnosing problems in production, investigating incidents across several servers, automating recurring DevOps tasks. I integrate them in two ways, depending on what is needed. With the Model Context Protocol (MCP) I connect the tools directly to the environments I work on, so the assistant reasons on the real context instead of a second hand description. With the APIs, instead, the model goes inside the code, with automations, bulk processing and product features.
The rule I use them by is the same that holds for any diagnosis, the tool speeds things up, but the technical direction, the verification and the decision stay mine. A hypothesis suggested by a model is worth as much as a hunch, until it is verified against evidence it is not an answer.