How to Build an Internal AI Tool Without Your Compliance Team Blocking It

You've built a prototype. It's brilliant. An internal tool that uses GPT-4 to summarise customer conversations, or classify support tickets, or draft responses. The team loves it. Usage is growing.

Then compliance finds out.

The conversation goes something like this:

"You're sending customer data where?"
"To OpenAI. It's just for internal..."
"Do we have a DPA with them?"
"A what?"
"A Data Processing Agreement. GDPR Article 28. If we're sending personal data to a third party for processing, we need a DPA."
"I think they have a standard one..."
"Does it cover our specific use case? What data categories are we sending? What's our legal basis? Have we done a DPIA?"
"...I'll get back to you."

The prototype gets blocked. The team is frustrated. Compliance isn't wrong; they're just doing their job.

The Pattern I Keep Seeing

This happens at almost every mid-sized company adopting AI tools. Engineering builds something useful with customer data. Compliance finds out late. The project either dies or enters a 3-6 month compliance review process that kills momentum.

The root cause isn't that AI features are inherently non-compliant. It's that most prototypes are built in a way that creates unnecessary compliance complexity. Specifically: they send raw customer data to third-party AI providers when they don't need to.

The Fix Is Architectural, Not Legal

If your AI tool receives customer data that contains PII, and you strip that PII before it reaches the LLM, your compliance picture changes dramatically:

No personal data reaches the third party, which simplifies the DPA scope and reduces your data protection risk
Data minimisation is demonstrable: GDPR Article 5 satisfied
No PII in LLM provider logs: reduced breach surface
Compliance team can verify: the redacted prompts are auditable

Here's the architecture:

Customer data → ComplyTech (strip PII) → OpenAI/Claude (process clean data) → Response

The LLM still gets the full context of the support ticket, the customer complaint, the conversation, but it doesn't get the names, emails, and addresses. And as we've found, the LLM doesn't need those to do its job well. Summarisation quality is identical with or without the customer's actual name.

Implementation

import requests
import openai

def build_ai_summary(ticket_text):
    # Strip PII before it reaches OpenAI
    clean = requests.post(
        "https://api.comply-tech.co.uk/api/v1/anonymise",
        headers={"X-Api-Key": "your-api-key", "Content-Type": "application/json"},
        json={
            "content": ticket_text,
            "contentType": "text",
            "strategy": "Redact",
            "frameworks": ["GDPR"]
        }
    ).json()["anonymisedContent"]

    # Now send clean data to the LLM
    response = openai.chat.completions.create(
        model="gpt-4",
        messages=[{
            "role": "system",
            "content": "Summarise this support ticket. Note that personal details have been redacted for privacy."
        }, {
            "role": "user",
            "content": clean
        }]
    )
    return response.choices[0].message.content

How to Present This to Your Compliance Team

Don't go to compliance after building the tool. Go before, with this:

"We want to build an AI-powered ticket summarisation tool. Here's our proposed architecture. Customer data passes through a PII sanitisation API before reaching the LLM provider. No personal data leaves our control. We can show you the redacted prompts in an audit log. Here's a demo."

That conversation goes very differently from "we've been sending customer data to OpenAI for three weeks."

Try the PII Stripping