Cloud, data and AI in production

No, and waiting for a perfect platform is usually a mistake. The sequence matters because production AI needs governed, reachable data, but the two threads can run in parallel: a bounded AI pilot on one well-understood dataset while the broader migration progresses. DNA Solutions often runs both at once, with the pilot scoped so its data sources are among the first workloads migrated. What we advise against is scaling AI across the organization on top of a fragmented legacy estate, because every model then inherits the data quality problems underneath it. Start the pilot early, but let the platform catch up before you generalize.

The choice follows three questions: where is your data legally allowed to reside, what does the workload profile actually require, and what tooling do your teams already operate. AWS and Azure European regions cover most enterprise cases, and we pick between them on workload fit rather than preference. Sovereign European hosting becomes the right answer when public sector requirements, sector regulation or strategic independence rule out hyperscaler dependency, particularly for AI workloads processing sensitive documents. Because we engineer for portability, with infrastructure as code and open standards, the decision is revisable later rather than a one-way door.

We bring business information into a consistent reporting layer and develop useful indicators with end users.

As design constraints, settled before the first deployment rather than reviewed after it. For GDPR that means data residency in European regions or on sovereign hosting, minimization built into pipelines, access controls and audit trails at the platform layer, and support for your DPIA process. For the AI Act it means classifying each use case by risk category, documenting models and training data so they can withstand scrutiny, and keeping humans in the loop where the regulation requires it. Where the requirements rule out hyperscaler AI services entirely, we train and run custom models on European infrastructure with no external API dependency.

That is the normal setup, and the handover is planned from the start rather than improvised at the end. Your engineers work inside the project, the infrastructure is managed as code so every environment is reproducible, and the architecture is documented end to end. By the time the platform is stable, your team operates it day to day, and we stay involved where it makes sense: new stages of the stack, model retraining, or capacity your team does not need to build in-house. The dependency you keep should be a choice, never a consequence of how the system was built.