AI 智能體接觸個人資料前，如何建立控制台帳

Before an AI Agent Touches Personal Data, Build This Control Ledger

An AI agent does not create a new privacy problem so much as it compresses several old problems into one fast-moving system. A conventional application receives a request, executes known code, and returns a bounded response. An agent can interpret an open-ended goal, select tools, retrieve context, create intermediate notes, call another agent, and take an external action. That flexibility is useful. It also means that a privacy review based only on the model name or the user interface misses most of the actual data path.

The practical question is therefore not “Is this agent GDPR compliant?” Compliance is not a property that a vendor can attach to a model. The useful question is: can the operator show, for every meaningful action, what personal data entered the system, why it was needed, which component received it, what authority permitted the action, what evidence was retained, and how the action could be stopped or reversed?

This guide turns that question into an operating system. It adapts an existing checklist on AI agents and GDPR controls into an implementation method for teams shipping agents. The result is a control ledger, not another policy document. It connects the record of processing activities, tool permissions, data minimisation, human approval, retention, incident response, and production evidence.

The design is intentionally conservative. It does not assume that a model will behave deterministically, that a prompt will remain confidential, or that a successful benchmark predicts safe production behaviour. Stanford’s 2026 AI Index reports that agents still fail roughly one in three attempts on structured computer-use benchmarks, even after large gains in capability. That is a useful counterweight to vendor demos: capability is improving, but a production control must expect failure rather than treat it as exceptional.

The decision this ledger supports

At each deployment gate, the owner should be able to make one of four explicit decisions:

“Allow” must never mean “the model seems good.” It means the complete path has a bounded purpose, the minimum necessary data, enforceable permissions, observable execution, a stop mechanism, and an accountable owner. If one of those elements is absent, the correct state is conditional or denied.

Start with the processing path, not the chatbot screen

A useful privacy inventory follows data from collection to deletion. For an agent, that path often contains more components than the product diagram shows:

1. A person submits text, a document, an email, audio, or an identifier.
2. An application adds account attributes, conversation history, or retrieved records.
3. A model provider receives a prompt and returns a proposed next step.
4. An orchestration layer decides whether to call a tool.
5. The tool reads or changes a system of record.
6. A memory or vector store retains selected context.
7. Logs, traces, evaluation datasets, and support exports create additional copies.
8. A human reviewer may receive the output through another service.
9. Backups and security systems may retain evidence after the operational record expires.

The privacy boundary is the union of those paths. A team that documents only the model call will underestimate processors, locations, retention periods, and downstream consequences. The ledger must therefore describe a processing episode, not just a prompt.

flowchart LR
    A[Person or source system] --> B[Input classifier]
    B --> C{Purpose allowed?}
    C -- no --> D[Reject and record reason]
    C -- yes --> E[Minimise and label data]
    E --> F[Agent runtime]
    F --> G{Tool action risk}
    G -- read, low risk --> H[Policy-enforced tool]
    G -- write or external --> I[Human approval]
    I -- approved --> H
    I -- rejected --> J[Stop and preserve evidence]
    H --> K[System of record]
    F --> L[Redacted trace]
    K --> M[Outcome and reversal status]
    L --> N[Retention and deletion jobs]
    M --> N

This map makes two ideas visible. First, minimisation happens before model and tool access, not after a leak. Second, approval is attached to an action class, not to the whole agent. A customer-service agent may read a delivery status automatically while requiring approval to change an address, issue a refund, or send an external message.

Build one row per processing episode

The ledger can live in a database, a governed catalog, or a versioned configuration repository. The implementation matters less than the contract. One row should identify a repeatable processing episode such as “summarise an applicant file for a recruiter” or “draft a reply to a customer requesting account deletion.” Avoid a single row called “AI assistant”; it is too broad to support a lawful-basis analysis, a retention rule, or an access decision.

Each row needs the following fields:

• Purpose ID and plain-language purpose. State the result for the person or business process. “Use AI” is not a purpose.
• Controller and operational owner. The controller determines why and how the processing occurs; the operational owner can stop the runtime today.
• Affected people. Customers, applicants, employees, prospects, patients, suppliers, or other groups may face different risks.
• Data classes. Separate direct identifiers, contact details, behavioural data, content, financial data, credentials, special-category data, and inferred attributes.
• Collection source. Direct user input, an internal record, a third party, public data, or an inference must not be conflated.
• Lawful basis and condition. Record the basis selected by qualified privacy counsel and the operational condition that keeps it valid. Do not let the agent invent this field.
• Recipients and processors. Include the model host, observability provider, vector database, annotation vendor, ticketing system, and every tool endpoint.
• Geography and transfer mechanism. Record processing locations and the approved transfer arrangement where required.
• Tool scope. List each operation as read, propose, create, update, delete, communicate, or transact.
• Human gate. Name the decisions that require approval and the role allowed to approve them.
• Retention clock. Give a trigger and duration for prompts, outputs, traces, memories, evaluation samples, and backups separately.
• Rights path. Explain how records are found, exported, corrected, restricted, objected to, or deleted.
• Evidence references. Link the policy version, test suite, risk assessment, processor terms, deployment record, and incident runbook.
• Kill switch and rollback owner. A stop control without a named operator and tested procedure is only a diagram.

The distinction between data content and operational evidence deserves care. A full prompt may contain unnecessary personal data, while an audit event can often prove what happened using a subject pseudonym, purpose ID, tool name, policy decision, timestamps, and hashes. “Log everything” is not a defensible default. “Retain the minimum evidence required to investigate and demonstrate the control” is a better engineering target.

Translate purpose limitation into runtime policy

Most privacy documents state a purpose but do not enforce it. Agents make that gap dangerous because the same credentials and tools can often serve many goals. Purpose limitation becomes real only when the runtime rejects actions that are technically possible but outside the approved episode.

Represent the grant as a small, reviewable object. The following JavaScript example is executable and intentionally does not depend on a model. It evaluates an action request against purpose, data class, tool, operation, approval, and expiration.

const grants = {
  "support-delivery-status": {
    dataClasses: ["customer_id", "order_status"],
    tools: { orders: ["read"] },
    requiresApproval: [],
    expiresAt: "2026-12-31T23:59:59Z"
  },
  "support-address-change": {
    dataClasses: ["customer_id", "postal_address"],
    tools: { orders: ["read", "update"] },
    requiresApproval: ["orders:update"],
    expiresAt: "2026-12-31T23:59:59Z"
  }
};

function authorize(request, now = new Date()) {
  const grant = grants[request.purposeId];
  if (!grant) return { allow: false, reason: "unknown_purpose" };
  if (now > new Date(grant.expiresAt)) {
    return { allow: false, reason: "expired_grant" };
  }

  const unexpectedData = request.dataClasses.filter(
    (item) => !grant.dataClasses.includes(item)
  );
  if (unexpectedData.length) {
    return { allow: false, reason: "data_not_minimised", unexpectedData };
  }

  const operations = grant.tools[request.tool] || [];
  if (!operations.includes(request.operation)) {
    return { allow: false, reason: "tool_operation_not_allowed" };
  }

  const action = `${request.tool}:${request.operation}`;
  if (grant.requiresApproval.includes(action) && !request.approvalId) {
    return { allow: false, reason: "human_approval_required" };
  }

  return { allow: true, reason: "policy_match" };
}

console.log(authorize({
  purposeId: "support-address-change",
  dataClasses: ["customer_id", "postal_address"],
  tool: "orders",
  operation: "update"
}));

Run this policy outside the model. The model may propose the purpose and action, but deterministic code validates the grant. Bind the decision to a short-lived agent identity, the requesting human or system, and the exact tool call. A general API key stored in a prompt or shared across agents defeats the control because there is no reliable delegation trail.

CISA and the UK National Cyber Security Centre place secure-by-design responsibilities across design, development, deployment, and operation rather than at a final review. That lifecycle framing matters here: a policy that existed at launch can become false after a new tool, a new data source, or a vendor configuration change. The ledger needs versioning and re-approval triggers.

Separate identity, delegation, and action authority

Three identities can be involved in one call:

• the person whose data is being processed;
• the employee, service, or workflow that delegated a task;
• the agent workload that executed a tool call.

Do not merge them into a single “user” field. The agent needs its own workload identity. The delegation record should say who or what asked it to act, for which purpose, with which scope, and until when. The tool should authorize the agent identity and verify the delegated context. Audit events should preserve all three relationships without exposing more personal data than necessary.

BCG’s control-plane guidance argues for centralized agent identity, registry, runtime policy enforcement, and deployment “golden paths.” The useful operational lesson is not that every company needs a large new platform. It is that each agent should enter production through the same enforceable path: registered owner, bounded identity, declared tools, observable policy decisions, spending and action limits, and a supported shutdown procedure. A spreadsheet inventory without runtime enforcement will drift. Runtime enforcement without an inventory will create controls no owner can interpret.

Use short-lived credentials where the platform permits them. Restrict tokens to an environment and a tool. Rotate secrets automatically. Deny tool discovery by default if the agent has no approved purpose for those tools. Treat agent-to-agent calls as new delegations, not as internal implementation details. An upstream agent cannot pass more authority than it received.

Minimise before retrieval and again before action

Data minimisation is often reduced to deleting unused database columns. Agents require two additional checks.

The first is retrieval minimisation. A semantic search can return a relevant paragraph surrounded by names, notes, or attachments that the task does not need. Apply access control before retrieval, filter by purpose and tenant, reduce the returned fields, and cap the context. Do not retrieve a whole employee file to answer a question about a training date.

The second is action minimisation. An output can combine facts into a new inference or disclose more than the target system requires. Before a tool call, validate the payload schema, permitted fields, destination, and action size. For external communications, show the human reviewer the actual recipient, subject, attachment list, and final body—not a vague summary saying “send customer update.”

Practical minimisation tests include:

1. Remove one data class and rerun the task. If success is unchanged, remove that class from the episode.
2. Replace direct identifiers with stable pseudonyms in traces and evaluation datasets.
3. Test retrieval with a user who lacks access to a neighbouring team or tenant.
4. Inject special-category data into a document and verify that it is blocked or redacted before an unapproved processor receives it.
5. Ask the agent to include “all helpful context” and confirm that the policy layer still restricts the payload.
6. Measure the largest prompt, retrieval result, tool payload, and log event observed in testing; outliers often expose hidden copies.

Minimisation is not a single filter. It is a sequence of decisions at collection, retrieval, model input, tool action, logging, evaluation, and retention.

Make human approval a control, not theatre

A nominal human-in-the-loop step can fail in three ways: the reviewer cannot see what matters, the volume makes rejection unrealistic, or the action happens before approval. The ledger should specify the approval object and its service-level constraints.

For a consequential action, the reviewer needs:

• the proposed action in its final form;
• the person or account affected;
• the facts used and their sources;
• uncertainties and missing evidence;
• the policy rule that triggered review;
• the difference from the current system state;
• the maximum consequence, including money, access, disclosure, or external communication;
• approve, edit, reject, and escalate choices;
• an expiry time so an old approval cannot authorize a changed action.

Sample the approval queue for rubber-stamping. Track rejection and edit rates, time spent, after-the-fact reversals, and reviewer disagreement. A zero rejection rate is not automatically good news; it may mean the gate is attached to trivial actions or that reviewers cannot challenge the proposal.

High-risk actions should be idempotent where possible. Use a transaction or staging state, create a reversal reference, and prevent a retried agent run from applying the same action twice. Human approval does not compensate for a tool that cannot safely retry.

Retention requires separate clocks

“We delete conversations after 30 days” rarely describes the whole system. A single episode can create operational records, model-provider logs, application telemetry, security events, vector embeddings, human review notes, evaluation examples, backups, and downstream business records. Each copy needs its own trigger, period, owner, and deletion mechanism.

Use event-based clocks. For example:

• Raw input: delete after the support case closes plus the approved operational period.
• Agent working memory: delete when the episode ends unless a documented continuation purpose applies.
• Redacted trace: retain long enough to investigate incidents and demonstrate controls.
• Evaluation sample: admit only through a separate sampling policy; remove direct identifiers first.
• Tool outcome: follow the retention rule of the system of record, not the chat interface.
• Approval evidence: retain with the consequential action it authorized.
• Backup copy: expire through the backup lifecycle and prevent ordinary restoration from silently reviving deleted memory.

Deletion verification must be testable. Select a synthetic subject, exercise the full path, invoke the deletion workflow, and check every registered store. Record stores that cannot delete individual records and document the compensating controls and expiry. An API that returns “accepted” is not proof that all copies disappeared.

Rights requests need an identity-resolution plan. Searching only by email misses pseudonymous trace IDs; searching every log for names can create a new exposure. Maintain a controlled mapping that can locate relevant episode IDs, then query each store through an audited workflow.

Evaluation must test privacy behaviour, not only task success

An agent can complete the task and violate the control. Evaluation therefore needs two scorecards: outcome quality and policy behaviour. Stanford’s benchmark work warns that benchmark quality varies widely and that implementation is often the weakest phase. Treat a public score as capability context, not acceptance evidence for your data and workflows.

Build a scenario suite from the ledger. Include:

• a valid request using only necessary data;
• a valid request containing extra personal data;
• an instruction to use an unapproved purpose;
• prompt injection in a retrieved document;
• a request to call a write tool without approval;
• cross-tenant and cross-role retrieval attempts;
• a revoked user or expired delegation;
• a tool timeout followed by a retry;
• a person exercising access, correction, objection, restriction, or deletion rights;
• a processor outage or regional-routing failure;
• an output that infers a sensitive attribute from ordinary fields;
• an agent-to-agent handoff that attempts to widen scope.

For each scenario, declare the expected policy decision before running the test. Preserve the policy version, test data classification, agent version, tool versions, result, and reviewer. A pass rate without case-level evidence cannot explain a production failure.

Do not put real customer data into routine evaluation merely because it is realistic. Start with synthetic cases and deliberately constructed edge cases. If production samples are necessary, define a separate purpose, sampling rule, access group, redaction step, retention period, and approval.

Failure modes the review must actively hunt

Purpose drift

The agent begins as a support drafting tool and gradually receives sales, fraud, HR, or collections tasks. Its credentials remain unchanged while the stated purpose becomes meaningless. Detect drift by comparing production tool calls and data classes with the approved ledger row. New combinations trigger review.

Memory contamination

A useful fact from one person’s episode appears in another person’s response because a memory namespace or retrieval filter is wrong. Test tenant isolation and subject boundaries with canary records. Prefer explicit namespaces and server-side access filters over prompt instructions such as “do not reveal other users.”

Processor shadowing

A developer adds a tracing, prompt-management, or annotation service that receives full content but is absent from the processor inventory. Egress monitoring and dependency review should compare observed destinations with registered recipients. Block unknown endpoints in production.

Excessive logging

Debug mode captures complete prompts, credentials, documents, or tool responses. Make redaction the default library path, prohibit secrets in prompts, scan traces for forbidden data classes, and time-limit elevated diagnostics.

Approval bypass

The agent calls a lower-level endpoint that performs the same action without the approval middleware. Enforce policy at the tool gateway or target service, not only in orchestration code. Inventory equivalent operations and deny direct credentials.

Stale consent or objection state

The system caches an eligibility decision and continues processing after a person withdraws consent or objects. Use live policy checks for consequential actions, short cache lifetimes, and invalidation events. Record which state was evaluated for each episode.

Irreversible action without recovery

An approved message goes to the wrong recipient, an account update overwrites valid data, or a deletion removes more than intended. Before granting write authority, test idempotency, staging, reversal, reconciliation, and notification procedures.

Silent model or tool change

A provider upgrades a model or a tool schema changes. The agent remains online but the validated behaviour no longer matches production. Pin versions where possible, watch release and schema events, run regression suites, and define changes that force re-approval.

Evidence without meaning

The organization stores millions of trace events but cannot answer who approved a specific action or which purpose authorized it. Design events around investigation questions. Test the reconstruction of a synthetic incident from start to finish.

The production evidence packet

For each release, assemble a compact packet that a privacy, security, product, and operations reviewer can understand without reading every prompt. It should contain:

1. The approved ledger row and purpose statement.
2. A current data-flow diagram, including processors and locations.
3. The lawful-basis decision and applicable assessment references.
4. Processor and transfer documentation references.
5. The agent identity, delegated scopes, tools, and action limits.
6. The minimisation rules and data classification mapping.
7. The approval matrix and screenshots or fixtures showing the review experience.
8. Evaluation cases, expected results, actual results, and unresolved limitations.
9. Retention and rights-workflow tests.
10. Monitoring queries, alert thresholds, kill-switch procedure, and rollback test.
11. Release identifiers for the model configuration, orchestration code, policy, prompts, retrieval index, and tool schemas.
12. Named owners and the next review date.

Hashing artifacts can help detect change, but a hash is not an explanation. Keep human-readable versions under access control. Connect deployment evidence to the exact runtime release so an auditor does not receive a policy written after the event.

Useful operational metrics include denied tool calls by rule, unregistered destination attempts, approval edits and rejections, cross-boundary retrieval tests, deletion completion time, trace-redaction failures, stale grants, emergency stops, rollback success, and incidents by processing episode. Do not optimise for a single “compliance score.” A composite score can hide one catastrophic weakness behind many easy checks.

A 30-day implementation sequence

Days 1–5: inventory and freeze authority growth

List production and pilot agents, owners, identities, data sources, processors, memories, and tools. Temporarily deny new write tools until they enter the inventory. Select the highest-impact episodes: external communications, decisions about people, special-category data, money movement, production changes, and bulk access.

Days 6–10: write the ledger rows

Split broad agents into processing episodes. Assign purpose IDs, affected groups, data classes, lawful-basis references, recipients, tool operations, human gates, retention clocks, rights paths, and stop owners. Reject vague rows. Confirm that the original source and privacy notice accurately describe the operation.

Days 11–15: enforce identity and policy

Give every agent a distinct workload identity. Replace shared long-lived keys where feasible. Put tool calls through the policy decision point. Bind purpose, delegation, data class, operation, environment, expiry, and approval. Log allow and deny decisions in a redacted evidence format.

Days 16–20: test adversarial and recovery paths

Run the scenario suite with synthetic data. Test injection, extra data, cross-tenant access, missing approval, revoked grants, retries, partial failures, deletion, and rollback. Fix enforcement at the boundary rather than adding more warning text to the prompt.

Days 21–25: rehearse operations

Have an operator stop the agent, revoke its credentials, drain queued work, preserve evidence, reverse a staged action, and restore service. Ask a privacy operator to complete a synthetic rights request across all stores. Record actual time and missing dependencies.

Days 26–30: release conditionally

Start with shadow or read-only mode. Review sampled episodes and policy denials. Open write actions by class, not all at once. Set an early review date and explicit rollback thresholds. Publish the owner and escalation route to support and incident teams.

The schedule is not a promise that every agent can be approved in 30 days. It is a way to expose missing controls quickly. A complex high-risk deployment may require a formal impact assessment, specialist legal review, consultation, or a redesign. The correct output of the process can be “do not deploy.”

Checklist for the release meeting

• [ ] One ledger row describes each distinct processing episode.
• [ ] The purpose is specific enough to reject unrelated requests.
• [ ] The data map includes retrieval, memory, traces, evaluation, approvals, tools, and backups.
• [ ] Each data class is necessary for the documented purpose.
• [ ] The lawful basis and any additional condition were selected by accountable specialists.
• [ ] Every processor, recipient, location, and transfer reference is registered.
• [ ] The agent has a unique workload identity and traceable delegation.
• [ ] Tool permissions are deny-by-default and enforced outside the model.
• [ ] Write, external, financial, access, and deletion actions have appropriate approval gates.
• [ ] Reviewers see the final action, affected record, evidence, uncertainty, and consequence.
• [ ] Approval cannot be replayed after the action or context changes.
• [ ] Retrieval filters and tenant boundaries were tested with canary records.
• [ ] Logs are redacted and still sufficient to reconstruct an episode.
• [ ] Prompts, outputs, memories, traces, evaluation samples, outcomes, and backups have separate retention clocks.
• [ ] A synthetic rights request succeeds across every registered store.
• [ ] Model, prompt, policy, index, and tool changes trigger defined regression tests.
• [ ] The kill switch, credential revocation, queue drain, rollback, and recovery were rehearsed.
• [ ] Monitoring has owners, thresholds, escalation routes, and review dates.
• [ ] Known limitations and residual risks are visible to the decision maker.
• [ ] The decision is recorded as allow, allow with approval, shadow mode, or deny.

Sources and limits

The operational starting point is the original checklist for agent ops in production. For secure lifecycle responsibilities, use the joint CISA and UK NCSC secure AI development guidance. For an independent view of current agent reliability and benchmark limitations, consult the Stanford HAI 2026 technical performance chapter. For enterprise identity, registry, runtime enforcement, and governed deployment paths, compare the BCG enterprise AI control-plane model. Teams operating in Europe should also ground their legal interpretation in the European Commission’s data-protection framework and obtain advice for their actual role, jurisdiction, and processing facts.

These sources do not remove the need for a fact-specific legal assessment. The ledger is an engineering and governance control, not a legal opinion. It cannot make an unnecessary purpose lawful, repair invalid consent, eliminate every model error, or guarantee that a platform provider satisfies contractual obligations. It can do something more concrete: make the system’s claims testable and make unsafe authority harder to exercise.

Final decision rule

Do not ask whether an AI agent is trustworthy in the abstract. Ask whether this processing episode is justified, minimised, bounded, observable, reversible where possible, and owned. If the team cannot reconstruct a proposed action before release and an actual action after execution, the agent does not yet have a defensible production path.

The strongest signal is not a long policy or a high benchmark score. It is a failed request that the system correctly refuses, with a reason an operator can understand and evidence a reviewer can verify. Build that refusal path first. Then earn additional authority one purpose, one data class, and one tool operation at a time.