AI Governance and Compliance in Microsoft and AWS Environments

AI is no longer an isolated workload — it is becoming a default capability inside Microsoft 365 (Copilot), AWS (Bedrock, SageMaker), developer tooling and dozens of SaaS apps that quietly added 'AI features' last quarter. Governance has to catch up, and in Europe the EU AI Act now makes that catch-up a legal obligation rather than a maturity goal.

This article walks through the practical AI governance baseline Cleverina implements for organizations running on Microsoft and AWS. It is built around three pillars: visibility, control and accountability.

1. Inventory: you can only govern AI you can see

The first deliverable on every AI governance engagement is an AI register. It records every AI system in use across the organization — including:

• Microsoft Copilot (M365, Copilot Studio, Copilot for Sales/Service, GitHub Copilot).
• AWS Bedrock foundation models, SageMaker endpoints, Q Business and Q Developer.
• Third-party SaaS with embedded AI features (CRM, support tools, marketing platforms).
• Internal models, agents and RAG pipelines built by data teams.

For each entry we capture purpose, data inputs, data outputs, user audience, the EU AI Act risk classification, and the responsible owner. This register is the spine of every downstream control.

2. Data boundaries before model boundaries

Most AI risk is not really model risk — it is data risk wearing a model hat. Copilot surfaces what your SharePoint sharing model already exposes. Bedrock answers from whatever you put in your knowledge base. The control is to fix the data plane first:

• Microsoft Purview sensitivity labels applied to high-value content, with auto-labelling for obvious categories.
• Restricted SharePoint Search or container-level scoping where over-sharing is endemic.
• AWS Bedrock guardrails for sensitive information filtering, denied topics and grounding to approved knowledge bases.
• PrivateLink / Private Endpoints for every AI service so that prompts and completions never traverse the public internet.

3. Acceptable-use policy: short, specific, enforced

Every organization we work with ends up needing a one-page AI Acceptable Use Policy aimed at employees, plus a more detailed AI Standard for builders. The employee policy answers four questions in plain language: what AI tools are approved, what data is allowed in prompts, how to handle outputs, and how to report concerns. The builder standard covers model selection, evaluation, red-teaming, logging and human-in-the-loop requirements for higher-risk use cases.

4. Map controls to the EU AI Act

The EU AI Act classifies systems by risk: unacceptable, high, limited and minimal. Most enterprise Copilot and Bedrock deployments fall into limited or minimal, but specific use cases — recruitment screening, credit scoring, biometric identification, critical infrastructure decisions — can land in high-risk and trigger the full compliance regime: risk management system, data governance, technical documentation, logging, transparency, human oversight and post-market monitoring.

Your AI register doubles as your Article 9 risk-management ledger. Wire the high-risk entries into a documented review cycle and you have the backbone of EU AI Act readiness.

5. Align with adjacent frameworks

AI governance does not exist in isolation. The same controls have to map cleanly onto:

• GDPR — DPIAs for AI processing of personal data, legal basis decisions and data-subject rights including the right not to be subject to automated decisions.
• NIS2 — AI systems that support essential services inherit incident-reporting and supply-chain obligations.
• ISO/IEC 42001 — the AI management system standard, complementary to ISO 27001 and an increasingly common procurement requirement.
• Sector regulators — DORA for financial services, MDR for medical devices, etc.

We build a single control mapping so the same evidence satisfies multiple obligations. Audit fatigue is real and avoidable.

6. Logging, monitoring and human oversight

Every AI system in scope should produce auditable logs: who invoked it, what prompt, what output, what action was taken downstream. On Microsoft, this means Purview Audit and the Copilot interaction logs. On AWS, CloudTrail data events for Bedrock and SageMaker, with model-invocation logs centralized to the security account. Combine with Defender for Cloud Apps or AWS GuardDuty for anomaly detection on unusual usage patterns.

Human oversight is not a documentation exercise — assign named reviewers for high-risk outputs, define when a human must approve before action is taken, and measure how often that override is exercised.

7. Operate the program

AI governance is a continuous practice: quarterly register reviews, model-evaluation refresh, red-team exercises for higher-risk systems, and a clear intake process for new AI use cases so shadow AI does not silently re-grow. Cleverina's AI Governance practice helps organizations stand this program up across Microsoft and AWS, with the operational telemetry to prove it works.

Where to start

Begin with the inventory. You cannot write a defensible policy, classify risks or design controls until you know what AI is actually being used and on what data. Most clients are surprised by what week one of that exercise turns up.

If you want a second set of hands on your AI governance program — Microsoft, AWS or both — explore our governance services or contact us for a scoped readiness assessment.