AI that works inside your system
Reduce manual work. Stay in control.
The data that matters is often raw and unstructured, scattered across files, business systems and tools that don’t talk to each other. We build software that gathers it, classifies it and makes it decision-ready.
What we build
Custom AI software
Custom systems that analyse data and documents, extract the relevant elements, and turn them into clear, ready-to-use assessments. Depending on the process, they can classify, verify, predict, or generate outputs and actions, supporting the judgement of the person deciding without ever replacing it. The AI handles the heaviest, most repetitive cognitive work; the final decision stays with the team.
Automations & workflows
We orchestrate tools, data, and steps into flows that run on their own, with Make, n8n, code, and APIs. An incoming order, a notification to send, an update to propagate: every repetitive action becomes automatic and repeatable. This drastically reduces manual work and frees up more hours for higher-value activities.
Portals & document systems
Web apps that become the single home for your documents: collected, organised, and always traceable in one place. Deadlines, requests, and approvals follow a clear path, with no lost emails or scattered files. Every piece of information is where it's needed, visible to the team in tidy portals and dashboards. They're often the operational interface of an AI system: the web app the team uses every day.
Integrations & data flows
We connect platforms, databases, and external services, making them interoperable and always in sync. Data stops being copied by hand from one system to another: it's updated once and stays consistent everywhere. An invisible infrastructure that connects the tools you already use.
Before asking what AI-enabled software can do, there is a more important question: what data will it use, where will that data be stored and processed, who will be able to access it, and what information will actually reach an AI service?
These are architectural decisions, not details to address later.
Infrastructure starts with the project requirements
The client defines the relevant operational needs, internal constraints, and geographic, contractual or regulatory requirements. We translate them into architectural decisions.
Databases, documents, files and services are then placed across providers, infrastructure and regions that are consistent with those requirements.
This does not mean that all data needs to reside in the same environment. In some projects, it may be appropriate to distribute databases, documents, storage, backups or other components across different infrastructure while keeping access, responsibilities and data flows between components clearly defined.
If specific data must remain in Italy, the European Union or another defined region, the architecture can be designed around that constraint. This means considering not only the primary database, but also storage, backups, logs, integrations and other services involved in processing the data.
Backup and recovery are also part of the architecture: having data available on a storage system or NAS does not automatically mean that an adequate strategy is in place to recover it in the event of loss, corruption or unavailability.
Data residency and data sovereignty are not the same thing
Knowing that data is hosted in Europe can be important when location is a requirement.
But geographic location is only one part of the picture.
Other factors may also be relevant, including the jurisdiction the provider is subject to, who manages the infrastructure and access controls, which external services are involved in processing, how encryption keys are managed, and which technology providers the system depends on.
For this reason, we do not treat labels such as “European cloud” as a universal answer. We assess the actual level of control and jurisdiction required for the specific project.
We limit what is sent to AI services
Integrating an AI model does not necessarily mean giving it unrestricted access to an organisation’s entire information environment.
Where the process allows it, we design the system so that only the information relevant to the specific task is retrieved and sent to the AI service, avoiding unnecessary access and data transfers.
The characteristics of the chosen service also need to be considered: where processing takes place, retention policies, available configurations, possible subprocessors and deployment options.
The actual characteristics depend on the provider and the specific service being used.
AI operates within the system
Before and after the model, there are software components, permissions, application rules, validations and controls.
The level of autonomy is calibrated according to the consequences of the action.
Analysing or classifying a document does not necessarily carry the same level of risk as sending a communication, modifying important data or completing an action that may be difficult to reverse.
Where the process requires it, we introduce operational limits, additional checks or human approval.
AI is one component of the architecture. Its scope is designed together with the rest of the system.
The architecture should remain aligned with the system over time
An architectural choice may be appropriate at one stage of a project and require review when volumes, team structure, integrations, requirements or operational criticality change.
For this reason, we do not treat infrastructure as an immutable decision. The structure of the system can be reassessed as the context evolves, avoiding both premature complexity and architectural choices that are no longer aligned with the requirements.
For some projects, a properly configured regional cloud environment may be sufficient. Others may require stricter conditions around data residency, infrastructure control, the external services involved or the location where processing takes place.
Depending on the project, we may therefore evaluate:
None of these configurations is inherently better in every context.
Greater control and isolation may also introduce additional operational complexity, maintenance requirements and cost. Managed services, on the other hand, may offer important advantages in areas such as reliability, updates and scalability.
We assess the data, the process, the constraints and the risk. Then we design the level of control that the system actually requires.
Insights
From website to AI automation: the evolution of a partnership
A real case: how we automated a foundation’s communication, and what it means to have a partner who stays over time.
Read the articleWhen custom software can make the difference
You don’t always need to build a custom system. In this guide we explain how to assess the process, the tools already in place, and the level of complexity before deciding.
Read moreWhere your data lives and what reaches AI models
Data residency, access and responsible use of AI: how we define security measures based on the project and the real risk.
Read the article