UK AI Engineering & Infrastructure Summit 2027

Beat the rush and join us early for complimentary barista-made coffee and breakfast.

As engineering teams building AI systems for financial services, healthcare, and other regulated sectors across the UK and EU face requirements around data residency, explainability, and algorithmic accountability, this keynote examines what it actually takes to build compliance into system architecture from the outset, rather than retrofitting it once a system is already in production.

• Concrete technical requirements flowing from the EU AI Act's classification of AI systems by risk level, and how that classification shapes data pipeline, logging, and model architecture decisions.
• Practical engineering approaches to keeping sensitive data within UK or EU jurisdictions while still accessing the compute and model infrastructure needed for competitive AI performance.
• What engineering teams are learning about the level of decision provenance and model documentation the ICO, FCA, and EU regulators genuinely expect, versus what teams initially assumed would be sufficient.

With the UK's AI compute capacity heavily dependent on a small number of international cloud and chip providers, this keynote examines the practical engineering and strategic implications of building critical AI infrastructure on a foundation the country doesn't itself control.

• How reliance on offshore cloud and chip providers shapes practical decisions around cost, latency, and contingency planning for UK-based AI infrastructure.
• Practical patterns teams are using to balance British data sovereignty ambitions against the reality that the most capable infrastructure often sits outside direct control.
• How emerging government initiatives around domestic compute capacity could reshape the infrastructure choices available to engineering teams in the coming years.

As engineering teams weigh AI Act compliance requirements alongside genuine commercial risk from provider dependency, this panel examines how teams are architecting systems that can genuinely operate across multiple model providers without the complexity becoming its own liability.

• Concrete examples of teams who've built provider-agnostic systems and found real resilience benefits, versus those where the abstraction added more complexity than protection.
• What it actually takes to maintain output consistency and reliability testing across providers whose models behave differently, rather than assuming a common interface solves the problem.
• Building the case internally for when consolidating on a single provider is the more defensible engineering and commercial decision, despite pressure to diversify for its own sake.

Serving customers across both the UK and EU with diverging data protection requirements post-Brexit, one SaaS platform's engineering leader built a unified data pipeline architecture that satisfied both jurisdictions' requirements without maintaining costly duplicate infrastructure.

• How the team identified the specific, genuine points of difference between the two frameworks rather than assuming full divergence and over-engineering separate systems.
• The architectural decision to build a single pipeline calibrated to whichever jurisdiction's requirement was more stringent for each specific data handling decision.
• How the team structured the system to adapt if UK-EU regulatory alignment shifted further, without requiring a full architectural rebuild each time.

A hands-on, interactive session working through a real production AI scenario as a room. Details announced soon.

After discovering that committed compute capacity from an offshore cloud provider couldn't guarantee the data sovereignty terms a government contract required, one systems integrator rebuilt the deployment plan around regional compute options under significant time pressure.

• How the team identified that their original compute plan wouldn't actually satisfy the sovereignty commitments made to the government client, before it became a delivery failure.
• The technical trade-offs made to fit the project onto compute resources that could genuinely satisfy sovereignty requirements, within the contract's timeline.
• How the team communicated the issue and the remediation plan to the government client in a way that preserved trust, rather than concealing the problem until it became unavoidable.

Facing the challenge of deploying a credit risk AI system classified as high-risk under the AI Act while formal technical guidance was still evolving, one fintech engineering leader built a defensible compliance approach based on the Act's principles, documenting every interpretive decision along the way.

• How the team approached genuinely ambiguous provisions of the Act, choosing conservative interpretations where the cost of over-compliance was lower than the risk of under-compliance.
• The structure built to ensure human reviewers could meaningfully understand and override system recommendations, rather than a token approval step.
• How the team maintained a living record of compliance reasoning throughout development, anticipating that regulators or auditors would eventually want to see not just the outcome but the reasoning behind it.

With UK GDPR and EU data protection frameworks diverging since Brexit, this panel examines how engineering teams serving both markets are architecting data pipelines and model infrastructure that satisfy both jurisdictions without maintaining fully separate, duplicated systems for each.

• Specific points where data handling, consent, or automated decision-making requirements differ enough between jurisdictions to force real architectural decisions.
• How some teams are building to the more stringent applicable requirement across both jurisdictions, rather than maintaining two parallel systems.
• How teams are building enough flexibility into their data architecture to adapt if UK-EU regulatory alignment changes, without needing a full rebuild each time.

Small-group, discussion-based sessions where you'll work through real AI engineering and infrastructure challenges with peers in similar roles. Roundtable topics will be announced soon.

Put your knowledge to the test in this fast-paced quiz covering real-world trivia, key concepts, and emerging trends. Compete for bragging rights — and a voucher — as the top scorer takes the crown.

Dealing with the gap between a research-grade AI diagnostic prototype and the infrastructure rigour required for deployment in an NHS-adjacent clinical setting, one healthtech engineer rebuilt core system components to meet the reproducibility, auditability, and safety documentation standards clinical deployment demanded.

• How the team identified specific technical debt in the original system that would never have satisfied the rigour clinical safety assessment required.
• The approach taken to lock down versioning and data lineage for clinically-deployed components while preserving flexibility in the team's ongoing research work.
• How the team built a genuinely collaborative relationship with safety assessment stakeholders, translating technical decisions into language that satisfied their review requirements.

This keynote examines how AI engineering teams across the UK and EU are building genuinely world-class infrastructure capability, and what the region's specific mix of talent, regulation, and market structure has forced practitioners to get right.

• How operating under a specific regulatory and talent landscape has shaped more deliberate engineering practices in some organisations across the region.
• What's genuinely working to build and keep strong technical teams, from compensation structures to the appeal of solving genuinely hard, regionally-specific engineering problems.
• Where UK AI engineering practice is genuinely distinctive and strong, and what still needs to be built to strengthen the region's position further.

As open-weight models offer teams greater control over deployment, data handling, and cost compared to closed API-based models, this interactive session discusses whether that control genuinely translates into easier regulatory compliance and lower total cost, or whether it shifts complexity onto engineering teams in ways that aren't always accounted for.

• Cases where running open-weight models in-house or in-region has made data protection and audit requirements meaningfully easier to satisfy.
• Honest accounting of the operational overhead that shifts onto engineering teams once they own the model rather than calling an API.
• How teams are building accurate cost comparisons between open-weight self-hosting and commercial API usage, factoring in the engineering time compliance and maintenance actually consume.

Unwind with your peers for a couple of drinks on us!

Beat the rush and join us early for complimentary barista-made coffee and breakfast.

As engineering teams building AI systems for financial services, healthcare, and other regulated sectors across the UK and EU face requirements around data residency, explainability, and algorithmic accountability, this keynote examines what it actually takes to build compliance into system architecture from the outset, rather than retrofitting it once a system is already in production.

• Concrete technical requirements flowing from the EU AI Act's classification of AI systems by risk level, and how that classification shapes data pipeline, logging, and model architecture decisions.
• Practical engineering approaches to keeping sensitive data within UK or EU jurisdictions while still accessing the compute and model infrastructure needed for competitive AI performance.
• What engineering teams are learning about the level of decision provenance and model documentation the ICO, FCA, and EU regulators genuinely expect, versus what teams initially assumed would be sufficient.

With the UK's AI compute capacity heavily dependent on a small number of international cloud and chip providers, this keynote examines the practical engineering and strategic implications of building critical AI infrastructure on a foundation the country doesn't itself control.

• How reliance on offshore cloud and chip providers shapes practical decisions around cost, latency, and contingency planning for UK-based AI infrastructure.
• Practical patterns teams are using to balance British data sovereignty ambitions against the reality that the most capable infrastructure often sits outside direct control.
• How emerging government initiatives around domestic compute capacity could reshape the infrastructure choices available to engineering teams in the coming years.

As engineering teams weigh AI Act compliance requirements alongside genuine commercial risk from provider dependency, this panel examines how teams are architecting systems that can genuinely operate across multiple model providers without the complexity becoming its own liability.

• Concrete examples of teams who've built provider-agnostic systems and found real resilience benefits, versus those where the abstraction added more complexity than protection.
• What it actually takes to maintain output consistency and reliability testing across providers whose models behave differently, rather than assuming a common interface solves the problem.
• Building the case internally for when consolidating on a single provider is the more defensible engineering and commercial decision, despite pressure to diversify for its own sake.

Serving customers across both the UK and EU with diverging data protection requirements post-Brexit, one SaaS platform's engineering leader built a unified data pipeline architecture that satisfied both jurisdictions' requirements without maintaining costly duplicate infrastructure.

• How the team identified the specific, genuine points of difference between the two frameworks rather than assuming full divergence and over-engineering separate systems.
• The architectural decision to build a single pipeline calibrated to whichever jurisdiction's requirement was more stringent for each specific data handling decision.
• How the team structured the system to adapt if UK-EU regulatory alignment shifted further, without requiring a full architectural rebuild each time.

A hands-on, interactive session working through a real production AI scenario as a room. Details announced soon.

After discovering that committed compute capacity from an offshore cloud provider couldn't guarantee the data sovereignty terms a government contract required, one systems integrator rebuilt the deployment plan around regional compute options under significant time pressure.

• How the team identified that their original compute plan wouldn't actually satisfy the sovereignty commitments made to the government client, before it became a delivery failure.
• The technical trade-offs made to fit the project onto compute resources that could genuinely satisfy sovereignty requirements, within the contract's timeline.
• How the team communicated the issue and the remediation plan to the government client in a way that preserved trust, rather than concealing the problem until it became unavoidable.

Facing the challenge of deploying a credit risk AI system classified as high-risk under the AI Act while formal technical guidance was still evolving, one fintech engineering leader built a defensible compliance approach based on the Act's principles, documenting every interpretive decision along the way.

• How the team approached genuinely ambiguous provisions of the Act, choosing conservative interpretations where the cost of over-compliance was lower than the risk of under-compliance.
• The structure built to ensure human reviewers could meaningfully understand and override system recommendations, rather than a token approval step.
• How the team maintained a living record of compliance reasoning throughout development, anticipating that regulators or auditors would eventually want to see not just the outcome but the reasoning behind it.

With UK GDPR and EU data protection frameworks diverging since Brexit, this panel examines how engineering teams serving both markets are architecting data pipelines and model infrastructure that satisfy both jurisdictions without maintaining fully separate, duplicated systems for each.

• Specific points where data handling, consent, or automated decision-making requirements differ enough between jurisdictions to force real architectural decisions.
• How some teams are building to the more stringent applicable requirement across both jurisdictions, rather than maintaining two parallel systems.
• How teams are building enough flexibility into their data architecture to adapt if UK-EU regulatory alignment changes, without needing a full rebuild each time.

Small-group, discussion-based sessions where you'll work through real AI engineering and infrastructure challenges with peers in similar roles. Roundtable topics will be announced soon.

Put your knowledge to the test in this fast-paced quiz covering real-world trivia, key concepts, and emerging trends. Compete for bragging rights — and a voucher — as the top scorer takes the crown.

Dealing with the gap between a research-grade AI diagnostic prototype and the infrastructure rigour required for deployment in an NHS-adjacent clinical setting, one healthtech engineer rebuilt core system components to meet the reproducibility, auditability, and safety documentation standards clinical deployment demanded.

• How the team identified specific technical debt in the original system that would never have satisfied the rigour clinical safety assessment required.
• The approach taken to lock down versioning and data lineage for clinically-deployed components while preserving flexibility in the team's ongoing research work.
• How the team built a genuinely collaborative relationship with safety assessment stakeholders, translating technical decisions into language that satisfied their review requirements.

This keynote examines how AI engineering teams across the UK and EU are building genuinely world-class infrastructure capability, and what the region's specific mix of talent, regulation, and market structure has forced practitioners to get right.

• How operating under a specific regulatory and talent landscape has shaped more deliberate engineering practices in some organisations across the region.
• What's genuinely working to build and keep strong technical teams, from compensation structures to the appeal of solving genuinely hard, regionally-specific engineering problems.
• Where UK AI engineering practice is genuinely distinctive and strong, and what still needs to be built to strengthen the region's position further.

As open-weight models offer teams greater control over deployment, data handling, and cost compared to closed API-based models, this interactive session discusses whether that control genuinely translates into easier regulatory compliance and lower total cost, or whether it shifts complexity onto engineering teams in ways that aren't always accounted for.

• Cases where running open-weight models in-house or in-region has made data protection and audit requirements meaningfully easier to satisfy.
• Honest accounting of the operational overhead that shifts onto engineering teams once they own the model rather than calling an API.
• How teams are building accurate cost comparisons between open-weight self-hosting and commercial API usage, factoring in the engineering time compliance and maintenance actually consume.

Unwind with your peers for a couple of drinks on us!