Integrating AI in products and services¶

AI-powered services are third-party platforms that provide AI capabilities for integration into DHI products, solutions, or internal systems. These require evaluation for data protection, contractual compliance, and architectural fit.

For the core AI policy, data protection rules, and governance, see the AI Guidelines.

Service Approval Status¶

Service	Status	Notes
Azure OpenAI (LLM APIs, embeddings)	Approved	Covered by DHI's enterprise agreement. Enables LLM-RAG, LLM-SQL, and other common LLM application patterns. Data protection requirements below must be met
Azure Cognitive Services (Speech, Vision)	Approved	Includes transcription, image analysis, OCR. Same enterprise agreement
Azure Document Intelligence (Document AI/OCR)	Approved	Invoice processing, form extraction, optical character recognition. Same enterprise agreement
Azure AI Foundry	Approved	Unified platform for building, deploying, and managing AI applications. Same enterprise agreement
Azure ML	Approved	Custom model training and inference endpoints. Same enterprise agreement
Azure Translator	Approved	Multi-language support in products. Same enterprise agreement
Lightning.ai	Approved	Data science platform with compute, LLM inference, and open-source model hosting. SOC 2 certified. Legal has reviewed T&Cs. Contact AI CoE for approval. DHI has an Enterprise agreement with a dedicated number of seats. For more information contact Clemens Cremer
Self-hosted vector databases on Azure (e.g., FAISS, Milvus)	Approved	Libraries or containers deployed within DHI Azure infrastructure — no data leaves DHI. Required for RAG patterns. Standard Azure infrastructure governance applies
Self-hosted graph databases on Azure (e.g., Neo4j)	Approved	Deployed within DHI Azure infrastructure — no data leaves DHI. For knowledge graphs. Standard Azure infrastructure governance applies
Third-party vector database SaaS (e.g., Pinecone)	On Request	Data leaves DHI infrastructure — requires AI CoE approval with data flow assessment
Non-Azure LLM APIs (OpenAI direct, Anthropic API, Gemini API)	On Request	Requires AI CoE approval — assess data residency and contractual terms
Non-Azure ML platforms (AWS SageMaker, Google Vertex AI)	On Request	Requires AI CoE approval
Non-enterprise AI services	Not Approved	Free-tier or consumer AI APIs must not be used with DHI or client data

To request approval for "On Request" services: Contact the AI CoE with details of the service, intended use case, and data flows. The AI CoE will coordinate with DHI Core IT and Legal as needed.

When deploying approved services in client-facing products, the Deployment Checklist must also be completed.

Data Protection Requirements¶

All data protection rules from the AI Guidelines - Data Protection apply to AI services. In addition, the following service-specific requirements must be met:

Requirement	Details
Zero data retention	Ensure the service does not use DHI or client data for model training - check for "zero data retention" options
Data residency	Verify data is processed in approved geographic regions (GDPR compliance)
Encryption	Data must be encrypted in transit (TLS) and at rest
Audit logging	Service should provide audit logs for compliance and incident investigation
Contractual safeguards	DPA (Data Processing Agreement) must be in place before use

To request approval: Contact the AI CoE with details of the service, intended use case, data flows, and client impact assessment.

Open-Source and Self-Hosted AI Models¶

Running or fine-tuning open-source models locally (e.g., LLaMA, Mistral, DeepSeek) may appear safer because data does not leave DHI infrastructure, but these models introduce their own risks including unvetted training data, licence restrictions on commercial use, lack of enterprise support, and the operational burden of hosting and securing the infrastructure. Consult with the AI CoE.

Reference implementations: A standard reference architecture for common LLM application patterns (RAG, LLM-SQL, etc.) using approved services is planned. This will be maintained as a separate repository with default technologies, models, and example implementations that teams can use as a starting point.

Custom and Fine-Tuned Models (External Platforms)¶

When using third-party platforms (e.g., Azure ML, AWS SageMaker, OpenAI fine-tuning API) to fine-tune a model on DHI or client data, the process creates a derivative asset that embeds proprietary knowledge into the model weights, making it difficult to audit, control, or revoke access to that data after the fact. Before any fine-tuning activity on an external platform, teams must ensure the training data is appropriately classified, client consent is obtained where applicable, the resulting model is stored securely within DHI-controlled infrastructure, and a clear data processing agreement is in place with the platform provider. Consult with the AI CoE.

AI in Client-Facing Products¶

When AI capabilities are embedded into DHI products or solutions delivered to clients, additional requirements apply beyond internal use. This checklist applies in addition to using approved services:

Deployment Checklist¶

Legal and contractual:

[ ] User-facing transparency - Inform users that they are interacting with AI, that outputs may contain errors, and that their data is processed by AI services. Where client data is involved, confirm that contractual terms cover AI processing (see written consent requirements)
[ ] Contractual coverage - Include AI-specific liability and accuracy clauses in the client contract. Contact Legal for standard contract language
[ ] Regulatory compliance - Check with Legal whether the AI use case is subject to EU AI Act or other sector-specific regulations

Technical:

[ ] Vet supply chain - Only use models, embeddings, and plugins from trusted sources. Verify third-party component provenance and licence terms before integration (OWASP LLM03)
[ ] Monitoring and logging - Implement usage tracking, audit trails, and anomaly detection for AI interactions in production. Monitor for misuse, hallucination patterns, and unexpected behaviour
[ ] Fallback and graceful degradation - Define what happens when the AI service is unavailable. Client-facing products must have a fallback plan — error messages, degraded non-AI functionality, or queued retry
[ ] Cost visibility - Set up billing alerts, spend thresholds, and usage reporting for LLM API consumption. Ensure costs are trackable per client or project

Security and Data Protection Requirements¶

Teams must also satisfy the data protection requirements and implement the following security controls. Prompt injection is not a theoretical risk — it is an active and evolving attack vector with no complete mitigation available today:

Authentication and authorisation - All user-facing AI systems must implement user identification and access controls. Anonymous access to AI-powered endpoints is not permitted
Treat all user input as untrusted - Apply input validation and sanitisation before passing content to LLMs. Do not assume users will interact with the system as intended
No unmanaged external data sources - AI agents and LLM chains must not call external data sources or APIs that have not been explicitly approved and managed by the team
Design for prompt injection - Assume prompt injection will be attempted. Apply defences including input filtering and least-privilege access for any tools or data the LLM can reach
Validate all output - Filter and validate LLM responses before returning them to users. Prevent leakage of system prompts, internal data, other users' data, or sensitive system information in responses (OWASP LLM02)
Rate limiting - Protect AI endpoints from abuse including token exhaustion and denial-of-wallet attacks. Apply per-user and per-session rate limits
Limit LLM capabilities - Restrict what actions an LLM-powered system can perform. Do not grant write access, command execution, or access to sensitive data unless strictly required and explicitly approved