18.2.2 Internal audit procedures

Imagine your organization deploys a new generative AI for customer support. Six months later, an internal audit discovers that the model’s training logs contain thousands of unredacted customer emails, a direct violation of your data retention policy and GDPR. The third-party assessment you passed before launch missed this because it focused on model performance, not the underlying data pipeline controls. This scenario highlights the critical difference between external validation and internal assurance.

While third-party assessments (as discussed previously) provide an external snapshot, internal audit procedures are your organization’s ongoing mechanism for self-examination. They are not about passing a test; they are about building and verifying the internal controls that ensure you are always ready for a test. For a red teamer, understanding these procedures is vital because your findings often become the primary evidence driving an audit’s focus.

The Four Pillars of an AI Internal Audit

An effective internal audit of an AI system isn’t just a code review or a policy check. It’s a holistic evaluation that connects high-level governance to technical implementation. You can structure this process around four essential pillars, moving from abstract rules to concrete evidence.

Pillar 1: Governance and Policy Review

This is the “paper audit.” The auditor’s first question is: “What are the rules?” You examine the organization’s AI-specific policies, standards, and governance frameworks. The goal is to verify that these documents exist, are approved, and align with external legal and regulatory obligations.

• Key Question: Does our AI ethics policy explicitly address fairness criteria required by the Equal Credit Opportunity Act (ECOA)?
• Evidence: Review of the AI governance charter, data handling policies, model risk management framework, and records of committee approvals.
• Common Failure: Policies are too generic. A policy that says “AI will be fair” is useless without defining fairness metrics, acceptable thresholds, and responsible parties.

Pillar 2: Implementation and Process Verification

Here, you move from “What are the rules?” to “Are people following the rules?” This pillar involves tracing the AI development lifecycle to see if the documented controls are actually implemented. It’s about finding the gaps between policy and practice.

• Key Question: Our policy requires data minimization. Can the development team prove that only necessary features were used to train the model?
• Evidence: Examining Jira tickets, Confluence documentation, Git commit histories, data pipeline configurations, and interviewing developers and data scientists.
• Common Failure: “Documentation debt.” The process used to build the model three months ago no longer matches the official documentation because of subsequent, undocumented changes.

Automated checks can be powerful tools for auditors in this phase. For instance, a simple script can scan logs to verify that PII-stripping functions were called before data entered the training environment.

# Pseudocode for an automated audit check
# This script scans training pipeline logs for compliance evidence

def check_training_logs(log_file_path, required_step="pii_redaction_complete"):
    """
    Scans logs to ensure a required compliance step was executed.
    """
    found_evidence = False
    with open(log_file_path, 'r') as f:
        for line in f:
            if required_step in line:
                found_evidence = True
                break
    
    if not found_evidence:
        # If the step is missing, flag it as an audit finding.
        report_finding(
            finding_id="AUD-AI-021",
            description=f"Missing evidence of '{required_step}' in training logs.",
            risk="High",
            recommendation="Ensure data sanitization is logged explicitly."
        )
    return found_evidence

Pillar 3: Technical and Model-Level Testing

This is where the audit gets hands-on and directly intersects with red teaming. The auditor, often in collaboration with security or ML engineering teams, performs targeted tests to validate specific compliance claims. Your red team reports are invaluable here, providing a pre-vetted list of potential control failures to investigate.

• Key Question: The team claims the model is robust against adversarial attacks. Can we reproduce a known attack to verify the implemented defenses?
• Evidence: Results from bias testing toolkits (e.g., AIF360), adversarial robustness benchmarks, and data leakage detection tests.
• Common Failure: Controls exist but are ineffective. For example, an input filter designed to block prompt injections can be bypassed with a simple character encoding trick.

Pillar 4: Reporting and Remediation Tracking

An audit that produces a report no one reads is a waste of resources. The final pillar ensures that findings are formally documented, assigned to owners, and tracked until closure. This creates an auditable trail of accountability and improvement.

• Key Question: For the data leakage finding from last quarter’s audit, what corrective actions were taken, and is there evidence they are now effective?
• Evidence: Formal audit reports, management responses, issue tracking system records (e.g., Jira), and follow-up testing results.
• Common Failure: “Report and forget.” Findings are acknowledged, but no resources are allocated for remediation, leading to the same issues appearing in the next audit cycle. This is a sign of a poor governance culture.

The Role of the Internal Auditor: Skeptic, not Adversary

Unlike a red teamer, an internal auditor’s primary role is not to “break” the system but to provide “reasonable assurance” that controls are designed and operating effectively. They operate with a mindset of professional skepticism. They must trust but verify.

When you, as a red teamer, demonstrate a successful prompt injection, the auditor translates that technical exploit into a business risk. Your finding of “I can make the chatbot swear” becomes the auditor’s finding of “Inadequate input validation controls leading to a high risk of reputational damage and potential violation of acceptable use policies.” This translation is crucial for getting management attention and resources for a fix. The internal audit process gives your technical findings a formal voice within the organization’s risk management structure, setting the stage for the continuous monitoring discussed next.