Logging, auditing and lineage

Hannah's favorite question for any system was "How would we know?" How would we know if someone used the summarizer to read transcripts they should not? How would we know if the no-show model quietly got worse at the rural clinics? How would we know which version of the model produced a particular score six months ago, and what data it had been trained on? Every answer led to the same place: records. If a system does not record what happens, nobody can check it, audit it or learn from it.

This lesson covers the records that make AI systems accountable: audit trails with AWS CloudTrail, logs of model invocations, monitoring and alarms, data and model lineage, and the balance between keeping enough to investigate and keeping too much personal information. The exam guide names audit trail and logging requirements for AI interactions as a security consideration, and data lineage and data cataloging as ways of documenting data origins.

Three kinds of records

Noor separated the records into three kinds, each answering a different question.

The audit trail: AWS CloudTrail

AWS CloudTrail records API calls made in an AWS account: who made the call, from where, when, what was requested and whether it succeeded. For AI systems this includes calls to Amazon Bedrock and Amazon SageMaker AI, such as invoking a model, creating or changing a guardrail, starting a training job, registering a model version or changing a knowledge base. Changes to IAM policies and KMS key use are recorded too.

Gwen had already set up an organization trail that collected CloudTrail events from every account into the security and log archive account, where the logs were stored in a bucket that nobody in the workload accounts could change or delete. For AI, she added two alarms. One fired when anyone changed a guardrail or a model access policy in production, because those changes should only happen through the release process. The other fired on an unusual volume of model calls from any role, as lesson 7 mentioned.

CloudTrail answers "who did what", but by default it does not record the full text of every prompt and response. That is the job of invocation logging.

Interaction logs: model invocation logging

Amazon Bedrock offers model invocation logging, which can deliver the details of each model call, including the input and output, to Amazon CloudWatch Logs, Amazon S3 or both. This is valuable: it lets a team investigate a bad answer, measure quality, spot misuse and build evaluation sets. It is also risky, because it creates a copy of everything users typed and everything the model said, including personal information.

Hannah and Noor made three decisions about the summarizer's interaction logs.

• Log metadata always, content carefully. Every call records which role called which model with which guardrail version, the time, the token counts and whether the guardrail intervened. Content is stored only after masking, through the same sensitive information filter the application uses.
• Protect and time-limit the logs. Logs are encrypted with a customer managed KMS key, stored in the home Region, readable only by Noor and Hannah, and deleted after one year by a lifecycle rule.
• Record guardrail interventions. When the guardrail blocks or masks something, the log says which policy acted. A rising number of blocked prompt attacks is a security signal; a rising number of blocked harmless questions means the guardrail is too strict.

aws bedrock put-model-invocation-logging-configuration \
    --logging-config file://invocation-logging.json

For the no-show model, interaction logging looked different. Each prediction was stored with the model version, the input features, the score and the top explanation factors, as lesson 3 described, so any score shown to a receptionist could be explained later. Amazon SageMaker AI endpoints can capture requests and responses for this purpose, and Model Monitor uses that captured data to check for drift.

Monitoring and alarms

Records are only useful if someone looks at them, and people cannot look at everything. Monitoring turns records into signals.

• Amazon CloudWatch collects metrics and logs from AWS services and applications, and raises alarms when a measure crosses a threshold. Bedrock publishes metrics such as invocation counts, latency, errors and token counts.
• SageMaker Model Monitor, with Clarify, watches deployed models for data quality drift, accuracy drift, bias drift and explanation drift, as lesson 4 described.
• Dashboards bring the key measures together for the people responsible. Andre's monthly dashboard for the no-show model showed reminder counts, the overall recall from follow-up data, the rural recall gap and the number of times staff used the "this looks wrong" button.

# Turn a month of no-show model results into the signals the governance group watches.
months = {
    "Aug": {"recall_city": 0.65, "recall_rural": 0.60, "flags_disputed": 4},
    "Sep": {"recall_city": 0.66, "recall_rural": 0.59, "flags_disputed": 6},
    "Oct": {"recall_city": 0.64, "recall_rural": 0.53, "flags_disputed": 15},
}
GAP_LIMIT = 0.08
for m, r in months.items():
    gap = round(r["recall_city"] - r["recall_rural"], 2)
    alerts = []
    if gap > GAP_LIMIT:
        alerts.append(f"recall gap {gap} exceeds {GAP_LIMIT}")
    if r["flags_disputed"] > 10:
        alerts.append("many disputed flags")
    print(m, "->", "; ".join(alerts) or "ok")

Aug -> ok
Sep -> ok
Oct -> recall gap 0.11 exceeds 0.08; many disputed flags

The numbers are illustrative, from Noor's rehearsal of the monitoring process with simulated data for the pilot. They show the point of combining signals: in the simulated October, both the fairness measure and the human feedback moved at once, which is much stronger evidence of a real problem than either alone.

Lineage: tracing outputs back to their origins

Lineage is the record of how something came to be: which data a dataset was built from, which dataset a model was trained on, which model version produced a prediction. Lesson 5 introduced it as part of documentation; here it becomes a working tool.

Several AWS features record lineage. The AWS Glue Data Catalog records datasets, their schemas and locations. Amazon SageMaker AI lineage tracking automatically records relationships between the steps of a machine learning workflow, such as which dataset and code a training job used and which model it produced. The SageMaker Model Registry records model versions, their approval status and links to their training jobs and model cards. CloudTrail records who started each step.

Lineage pays off when something goes wrong. Suppose Andre's team discovered that bookings from one clinic had been mislabeled for a month. With lineage, Noor could find every dataset version that contained those records, every model version trained on them, and every prediction those models made, and decide what needed to be retrained or rechecked. Without lineage, she would be guessing.

For generative AI, lineage includes the knowledge base: which documents, in which versions, were in the index when an answer was given. The website assistant stored the document version with each retrieved passage, so an answer citing the parking page could be traced to the exact version of that page.

Protecting the records themselves

Records are only trustworthy if nobody can quietly change them. An attacker who gets into an account often tries to switch off logging or delete logs to hide what they did, and an insider who made a mistake might be tempted to do the same. Gwen's design made that hard. The organization trail was created in the management account and could not be stopped from the workload accounts; a service control policy denied anyone the ability to stop or delete it. The log archive bucket used S3 Object Lock, which prevents objects from being deleted or overwritten during a retention period. CloudTrail log file integrity validation was turned on, which produces digest files that prove whether a log file has been changed since delivery. And access to read the logs was itself logged.

The same thinking applied to the AI-specific records. Model cards and evaluation reports were stored with version history, so an old version could always be produced. Approval decisions in the Model Registry recorded who approved and when. If an auditor asked, two years later, what the governance group had known when it approved model version 3, Noor could show exactly the card and the evaluation they had seen at the time, not a later revision.

Using records in an audit

Jonah asked what an AI audit would actually look like. Noor described the one she expected at the first annual review. An auditor, internal or external, would pick a sample of AI decisions and trace each one end to end: the prediction or summary, the model and prompt versions that produced it, the approval of that version, the evaluation it was approved on, the data it was trained or grounded on, the guardrail applied, the human review step and the access controls around it. For each step the auditor would ask for evidence, and the evidence would come from the records in this lesson. AWS Audit Manager can help by collecting evidence from AWS services against a control framework automatically, so much of it is ready before the auditor asks.

"An audit is just someone asking 'how would we know?' with a clipboard," Hannah said. If the records exist, it is a routine week. If they do not, it is a very long one.

Retention and the right amount of logging

The exam guide lists retention among data governance strategies, and logging is where retention decisions are hardest. Too little logging leaves a team blind. Too much logging creates a large store of personal information that must be protected, disclosed on request and eventually deleted. Noor's rule was to decide, for each kind of record, what question it answers, who needs it, and how long the question stays open.