Security, Privacy, and Responsible AI Architecture

Why this chapter matters

Introduction

Enterprise data architecture creates the pathways through which information is collected, integrated, stored, transformed, shared, and used. As organizations adopt cloud platforms, lakehouses, data products, generative AI, and agentic systems, those pathways become more numerous and more dynamic. Information that once remained within a small number of controlled applications may now flow through analytical environments, external services, retrieval systems, model endpoints, and automated workflows.

This expansion creates opportunity, but it also changes the security and privacy challenge. Protecting a database is no longer enough if sensitive information can be copied into an analytical workspace, included in a prompt, retrieved into an AI context, or exposed through an agent with excessive permissions. Similarly, a privacy policy is not sufficient if systems cannot identify personal information, enforce permitted uses, manage retention, or respond to deletion and access requests across distributed environments.

Security, privacy, and responsible AI are related but distinct architectural concerns. Security protects systems and information against unauthorized access, alteration, disruption, and disclosure. Privacy governs how information relating to individuals is collected, processed, shared, retained, and used. Responsible AI addresses the design and operation of AI systems in ways that account for reliability, transparency, human oversight, fairness, accountability, and potential harm.

These concerns intersect throughout the data and AI lifecycle. A secure system may still use personal information in ways that are inappropriate for the stated purpose. A privacy-compliant data store may still expose information through a poorly controlled AI application. An AI system may operate within its technical permissions yet produce unreliable recommendations that require additional oversight.

The Enterprise Data Architect must therefore design for more than perimeter protection. Security, privacy, and responsible-use requirements must be reflected in identity, data flows, metadata, platform architecture, model integration, retrieval, application design, operational monitoring, and governance.

This chapter develops an architectural approach to these responsibilities. It explores security foundations, privacy engineering, AI-specific risks, control patterns, and the role of architecture in enabling trustworthy innovation. The Meridian Financial Group case study demonstrates how these concerns can be integrated into a practical enterprise design.

18.1 Security, Privacy, and Responsible AI as Architectural Responsibilities

Security, privacy, and responsible AI are sometimes treated as specialist reviews performed after a solution has been designed. This approach can create expensive rework. A data platform may be built without adequate isolation between environments. An AI assistant may be developed using information that cannot legally or contractually be used for its intended purpose. An agent may be given broad access because authorization was not considered during the initial design.

These issues are difficult to resolve through policy documents alone. They require architectural decisions about where information is stored, how identities are established, how access is evaluated, which services can communicate, what information is retained, and how actions are approved.

Security, privacy, and responsible AI should therefore be treated as design concerns from the beginning of an initiative. This does not mean every project must perform an identical set of activities. The depth of analysis should reflect the sensitivity of the information, the impact of the use case, the exposure of the system, and the organization’s obligations.

The architect’s task is to make these concerns explicit. For example, a design should identify whether sensitive information is required at all, whether it can be minimized or transformed, which identities can access it, whether it crosses organizational or geographic boundaries, and how its use will be monitored.

A responsible architecture also recognizes that controls can introduce trade-offs. Stronger isolation may increase operational complexity. More detailed logging may improve accountability but create additional sensitive records. Broad data access may improve analytical flexibility but increase exposure. The goal is not to maximize every control independently. It is to establish a coherent control design that is proportionate to risk and compatible with the business purpose.

18.2 The Modern Enterprise Threat Landscape

The modern enterprise data environment has an expanded attack surface. Data may be accessed through applications, APIs, notebooks, orchestration services, query engines, object storage, event streams, external integrations, and AI interfaces. Each connection creates a potential route for misuse, compromise, or unintended disclosure.

Traditional threats remain relevant. Stolen credentials, excessive privileges, insecure configurations, vulnerable software, malicious insiders, and compromised third-party services can expose enterprise information. Cloud adoption changes where and how these risks must be managed, but does not remove them.

Data platforms also introduce risks associated with copies and derived information. Sensitive records may be replicated into development environments, temporary storage, analytical extracts, feature stores, or retrieval indexes. A control applied to the original source may not automatically protect every copy.

AI introduces additional pathways. An application may include retrieved documents in a model context. A user may submit sensitive information through a prompt. A model may return information that was not intended for that user. An agent may call a tool with broader permissions than the task requires. An attacker may attempt to manipulate the system through malicious instructions embedded in retrieved content.

These risks are not all solved by the same security mechanism. Identity and access management, network controls, data protection, application security, model governance, content validation, and operational monitoring address different parts of the problem. An effective architecture begins with an inventory of information assets, processing activities, identities, services, trust boundaries, and external dependencies. This creates a basis for threat modeling and control selection.

18.3 Security Architecture Foundations

Security architecture establishes how the enterprise protects identities, systems, data, networks, and operational processes. In a modern data environment, security should be designed as a set of coordinated controls rather than a single defensive layer.

A foundational principle is that access should be based on verified identity and explicit authorization. Users, applications, pipelines, and agents should have identifiable identities. Shared accounts and long-lived credentials make it difficult to determine who or what performed an action.

A second principle is least privilege. Each identity should receive only the permissions needed for its approved responsibilities. A data pipeline that reads one source and writes to one target should not have broad administrative access across the platform. An AI agent that retrieves approved policy documents should not automatically receive permission to modify customer records.

A third principle is defense in depth. No single control should be assumed to prevent every failure. Identity controls, network segmentation, encryption, application validation, data policies, monitoring, and incident response should work together. If one control fails, other mechanisms may still reduce exposure or enable detection.

A fourth principle is secure configuration by default. New environments, services, storage locations, and endpoints should begin with appropriate security settings. Unrestricted public access, broad permissions, and disabled audit capabilities should not be normal defaults.

A fifth principle is continuous verification. Access and risk should be reassessed as identities, workloads, data sensitivity, and operating conditions change. Security is not a one-time configuration exercise.

These principles should be reflected in enterprise architecture standards and reusable platform patterns. The more consistently they are built into the platform, the less each delivery team must implement from scratch.

18.4 Identity and Access Management

Identity and access management is central to enterprise data security. It establishes who or what is requesting access and determines whether that access should be permitted.

Modern data platforms must manage several identity categories. Human identities include employees, contractors, partners, and other users. Workload identities represent pipelines, applications, services, and automated processes. AI systems and agents may also require identities that distinguish them from the users who initiated their work.

Authentication verifies an identity. Authorization determines what that identity may do. These should be treated as separate architectural concerns. A successfully authenticated user should not automatically receive access to every data product or operation.

Role-based access control can simplify permission management by associating privileges with organizational roles. Attribute-based access control can evaluate additional context, such as data classification, user attributes, resource attributes, purpose, or environmental conditions. Many enterprises use a combination of these approaches.

For example, access to customer information may depend on a user’s role, business unit, jurisdiction, approved purpose, and the sensitivity of the requested attributes. A service identity may be permitted to read a limited set of fields but not export the full customer record.

Access governance should also address the full lifecycle of identities. Permissions should be granted through defined processes, reviewed periodically, and removed when no longer required. Temporary access should have an expiration or review condition. Privileged operations should receive additional controls and monitoring.

In AI applications, the distinction between user identity and application identity is especially important. A model endpoint may operate under an application identity, but that does not mean it should receive unrestricted access to the information available to the application. The architecture must ensure that user permissions and purpose restrictions are preserved as information moves through retrieval and model services.

18.5 Data Protection Across the Lifecycle

Data protection should be considered throughout the information lifecycle: collection, transmission, storage, processing, sharing, archival, and deletion.

Encryption protects information when it is stored or transmitted. It is an important control, but it does not determine whether an authorized application should be allowed to access the information. Encryption should therefore be combined with identity, authorization, key management, and monitoring.

Key management requires clear ownership and operational processes. Keys should be protected, access should be restricted, and rotation and recovery procedures should be defined. The architecture should also identify where encryption responsibilities belong to the enterprise, cloud provider, or service operator.

Data masking and tokenization can reduce exposure when full values are not required. Masking may hide selected attributes from particular users or environments. Tokenization replaces sensitive values with substitutes while preserving the ability to perform approved operations through a controlled service. These techniques should be selected according to the data’s use and the required reversibility.

Pseudonymization may reduce direct identification while preserving some analytical utility, but it should not be treated as equivalent to anonymization. If re-identification remains possible through additional information or a mapping mechanism, the data may continue to require privacy controls.

Data minimization is equally important. The safest sensitive information to expose is often information that the application does not need to collect or process in the first place. Architects should question whether a use case requires full records, whether selected attributes are sufficient, and whether derived or aggregated information can meet the business need.

Finally, deletion and retention must be designed into the lifecycle. Data may exist in primary storage, replicas, backups, logs, caches, indexes, and derived datasets. The architecture should define how retention and deletion requirements are applied across these locations, subject to applicable legal and operational constraints.

18.6 Privacy Engineering and Data Minimization

Privacy engineering translates privacy requirements into technical and operational design. It is concerned not only with preventing unauthorized disclosure but also with ensuring that personal information is processed appropriately.

A privacy-aware architecture begins with purpose. The organization should understand why personal information is collected, which purposes are permitted, and whether each processing activity is necessary for those purposes. A broad statement that information may be used to improve services does not automatically justify every possible secondary use.

Data minimization reduces the amount and detail of personal information used in a process. It may involve collecting fewer attributes, limiting retention, using aggregation, applying pseudonymization, or separating identity information from analytical records.

Purpose limitation should also be reflected in data product design. A product intended for service operations may contain attributes that are not appropriate for marketing analytics or model training. Reuse should be evaluated against the product’s stated conditions rather than assumed to be unrestricted.

Privacy engineering should consider the full data flow. A customer record may pass through an operational application, integration service, lakehouse, feature pipeline, model service, and reporting layer. Each transformation and destination should be considered when evaluating access, retention, and use.

The architect should work with privacy and legal specialists to understand applicable requirements. The architecture should not attempt to interpret legal obligations independently. Its role is to translate confirmed requirements into data flows, metadata, controls, and evidence.

18.7 Privacy Metadata and Data Discovery

Privacy controls are difficult to apply consistently when the organization cannot identify where personal or sensitive information exists. Metadata provides a foundation for discovery, classification, and policy enforcement. A privacy-aware metadata model may include data subject category, information type, sensitivity classification, processing purpose, source, jurisdiction, retention requirement, permitted use, and relevant policy references. The exact attributes depend on the enterprise’s needs and obligations.

Automated discovery tools can help identify likely personal information in structured and unstructured data. However, automated classification may be uncertain. A detected pattern may not always represent personal information, and personal information may exist in unexpected formats. Important classifications should have appropriate validation and ownership.

Metadata should be associated with data products, fields, documents, events, and derived assets where practical. It should also be propagated through transformations. If a pipeline creates a new table from sensitive source data, the resulting asset should not lose relevant handling requirements simply because its physical structure has changed.

Privacy metadata can support access policies, retention workflows, impact assessments, and catalog discovery. It can also help AI application teams identify whether a source is suitable for retrieval or model use. A mature architecture connects metadata to enforcement. Classification alone does not protect information. It becomes operational when access, masking, retention, and monitoring mechanisms use it to make decisions.

18.8 Security and Privacy in Cloud Data Platforms

Cloud data platforms distribute responsibilities between the enterprise and the cloud provider. The provider may secure physical facilities and underlying infrastructure, while the customer remains responsible for many aspects of identity, configuration, data access, workload security, and information use. The precise division depends on the service model and contract.

The shared responsibility model should be made explicit for each important service. Teams should understand which party manages encryption, identity integration, patching, network configuration, logging, backup, and incident response.

Cloud environments can support consistent controls through infrastructure as code, policy as code, centralized identity, managed key services, and automated configuration checks. These capabilities reduce reliance on manual setup and make security requirements more repeatable.

However, cloud flexibility can also increase configuration risk. Teams can create storage locations, compute resources, service accounts, and external connections quickly. Governance should therefore establish approved deployment patterns, guardrails, and monitoring for configuration drift.

Network architecture remains relevant, but it should not be treated as the sole basis for trust. A service operating within a private network may still be compromised or misconfigured. Access decisions should consider identity, resource, policy, and context.

For hybrid and multi-cloud environments, the architecture should establish consistent enterprise requirements while recognizing differences among platforms. A common security policy does not necessarily require identical technical implementation. It requires that the control objective and evidence remain clear across environments.

18.9 Data Sharing and Third-Party Risk

Enterprise data increasingly crosses organizational boundaries. Partners may receive data through APIs, managed file transfers, shared environments, or external platforms. AI services may process prompts or retrieved content outside the organization’s direct infrastructure. External sharing should be governed by business purpose, contractual conditions, security requirements, and privacy obligations. The architecture should identify what information is shared, with whom, through which interface, for how long, and under what controls.

Data minimization is particularly important in third-party integrations. The enterprise should expose only the information required for the service. Where possible, interfaces should avoid broad database access and instead provide purpose-specific APIs or data products.

Third-party risk assessment should consider the service’s security posture, data handling, retention, subprocessors, geographic processing, incident notification, and deletion capabilities. These considerations should be validated through the organization’s established risk and procurement processes.

AI services require additional attention. The organization should understand whether prompts or inputs are retained, used for model improvement, processed by subprocessors, or transferred across jurisdictions. Contractual and technical settings should align with the intended use and sensitivity of the information.

The architect should also consider exit and portability. If an external provider stores enterprise data, derived artifacts, or operational logs, the organization should understand how information can be retrieved, deleted, or transitioned when the service changes.

18.10 Responsible AI as an Architectural Discipline

Responsible AI concerns the design, development, deployment, and operation of AI systems in ways that account for their intended purpose and potential impact. It includes reliability, transparency, human oversight, accountability, and the management of risks such as unfair outcomes, misleading outputs, and inappropriate automation.

Responsible AI should not be reduced to a generic checklist applied to every system. Different AI applications have different levels of impact and uncertainty. A system that summarizes public internal documentation has a different risk profile from one that recommends actions affecting a person’s access to financial services.

The architecture should begin with intended use. What is the AI system designed to do? Who will use it? What decisions or actions may follow from its output? What information does it require? What are the foreseeable failure modes? What level of human review is appropriate?

The system’s limitations should be documented and communicated. A model may perform well on one class of tasks and poorly on another. A retrieval system may omit relevant information. A generative model may produce plausible but unsupported content. A predictive model may become less reliable as the environment changes.

Human oversight should be meaningful. A human reviewer needs enough information, time, authority, and expertise to assess a recommendation. A workflow that presents an AI output and requires a rapid approval without access to supporting evidence may provide only nominal oversight.

Accountability should also be clear. The organization should identify who owns the AI use case, who approves its deployment, who monitors it, and who can suspend it. Technical teams may operate the system, but business owners remain accountable for the decisions and processes in which it is used.

18.11 AI Risk Assessment and Proportionate Controls

AI risk assessment should be connected to the use case and its operating context. A model’s technical characteristics are important, but risk also depends on the affected population, decision context, scale, reversibility, available alternatives, and consequences of error.

A practical assessment begins by identifying the system’s intended purpose and prohibited or out-of-scope uses. It then examines the data sources, model behavior, user interaction, downstream actions, and dependencies. Risk analysis should consider at least four broad areas:

• Information risk concerns data quality, representativeness, provenance, privacy, security, and permitted use.
• Model risk concerns performance, robustness, uncertainty, drift, and the suitability of the model for the intended task.
• Interaction risk concerns how users interpret outputs, how prompts and retrieved content influence behavior, and whether users understand the system’s limitations.
• Operational risk concerns service availability, change management, monitoring, incident response, and the consequences of system failure.

Controls should be proportionate to the assessment. A low-impact internal assistant may require source restrictions, access controls, evaluation, and user guidance. A high-impact system may require independent validation, formal approval, stronger human review, detailed records, and ongoing monitoring.

Risk assessment should not end at deployment. The use case may change, new data sources may be introduced, model versions may be updated, and user behavior may evolve. The architecture should support periodic reassessment and controlled change.

18.12 Generative AI Security: Prompt Injection and Information Exposure

Generative AI applications introduce security concerns that arise from the interaction between instructions, retrieved content, user inputs, and tool access. Prompt injection occurs when untrusted content attempts to influence the model’s behavior by presenting instructions that conflict with the application’s intended behavior. Such content may appear in user prompts, retrieved documents, web pages, or other external sources.

The architecture should treat retrieved content as data, not as trusted instructions. System and application instructions should be separated from user and retrieved content, and the application should constrain which tools and actions are available. However, prompt design alone should not be treated as a complete security boundary.

Authorization must be enforced outside the model. A model should not decide whether a user is entitled to access a record based only on the content of a prompt. Retrieval services should apply access controls before information enters the model context. Tool APIs should independently verify the identity and authority associated with each action.

Information exposure can also occur through overly broad retrieval, excessive context, conversation history, logs, or generated outputs. The system should retrieve only the information needed for the task and avoid including sensitive data unnecessarily. Where outputs can trigger actions, the architecture should validate the action independently. A model-generated instruction to transfer funds, modify a customer record, or change an access permission should not be executed merely because it appears in a plausible response.

18.13 Agentic AI: Identity, Authority, and Control

Agentic AI systems can plan tasks, invoke tools, retrieve information, and execute sequences of actions. Their ability to act makes identity and authorization especially important.

An agent should have a clearly defined purpose and bounded authority. It should not receive broad access simply because it may need different capabilities in future scenarios. Tool access should be limited to the operations required for the approved task.

The architecture should distinguish the initiating user, the agent identity, and the identity used by downstream services. This helps establish whether an action was initiated by a user, proposed by an agent, approved by a person, or executed by a service.

Delegated authority should be explicit. If an agent acts on behalf of a user, the architecture should define which user permissions are inherited, which actions require additional approval, and whether the agent may continue operating after the user’s session ends.

High-impact actions should be protected by independent authorization and validation. An agent may prepare a payment instruction, but a separate service should verify limits, policy conditions, and required approvals before execution. The model should not be the final authority over its own permissions.

The architecture should also include limits on action frequency, resource consumption, and repeated tool invocation. Unexpected loops or faulty plans can create operational impact even without malicious intent.

Every significant agent action should be traceable to the task, identity, tool, input, policy decision, and outcome. This evidence supports investigation and helps the organization understand whether the agent operated within its approved boundaries.

18.14 Human Oversight and Meaningful Control

Human oversight is often presented as a general safeguard for AI, but its effectiveness depends on the design of the interaction and workflow. A human reviewer should understand what the system is recommending, what evidence supports the recommendation, and what limitations apply. The reviewer should have the authority to reject or modify the recommendation and sufficient time to exercise that authority.

The architecture should distinguish between approval, review, and monitoring. Approval occurs before an action is taken. Review may occur after a decision or at defined checkpoints. Monitoring observes system behavior over time. These mechanisms serve different purposes and should be selected according to the risk.

A human-in-the-loop process can fail if the volume of recommendations is too high, if the interface obscures uncertainty, or if organizational incentives encourage automatic acceptance. Human oversight should therefore be evaluated through actual workflow behavior, not simply the presence of an approval button.

The architecture should also define when the system must defer to a person. Examples include missing evidence, conflicting information, low reliability, policy exceptions, unusual requests, and actions outside approved boundaries.

In some cases, the appropriate control is not additional human review but a restriction on the system’s scope. A model that is unsuitable for a particular decision should not be made acceptable merely by placing a human somewhere in the process.

18.15 Responsible AI Evaluation and Monitoring

Evaluation should be designed around the intended use of the AI system. Generic model benchmarks may provide useful technical information, but they do not establish that a system is suitable for a specific enterprise workflow. For generative AI, evaluation may include factual accuracy, relevance, source support, completeness, instruction following, refusal behavior, and robustness to adversarial or misleading inputs. For retrieval systems, evaluation should also examine whether relevant and authorized information is retrieved.

For predictive models, evaluation may include performance across relevant segments, calibration, stability, and the consequences of different error types. The appropriate measures depend on the task and decision context.

Evaluation should include realistic cases, including edge cases and known failure conditions. It should also involve business users and subject-matter experts where the quality of outputs depends on domain context.

Monitoring extends evaluation into production. The organization should observe changes in input data, output patterns, user behavior, system performance, and business outcomes. Model or application updates should trigger appropriate testing before deployment.

Monitoring should also support incident response. If an AI system produces a harmful or materially incorrect result, the organization should be able to identify the affected workflow, relevant data sources, model and prompt versions, tool calls, and users or processes involved.

The architecture should retain enough evidence to support investigation while respecting privacy, retention, and data minimization requirements. Logging everything indefinitely is not an appropriate default. The organization should determine what evidence is necessary, how it is protected, and how long it is retained.

18.16 Security, Privacy, and Responsible AI in the Enterprise Operating Model

Technical controls are necessary, but they cannot substitute for an operating model that assigns responsibility and supports continuous oversight.

Business owners should define the purpose of data and AI use cases, understand their impact, and accept accountability for outcomes. Data owners should establish the meaning, quality, and permitted use of data products. Security teams should define security requirements and oversee relevant controls. Privacy specialists should advise on personal information and processing obligations. AI governance or risk functions should establish review and monitoring expectations for AI systems.

Platform teams should provide reusable capabilities such as identity integration, secrets management, encryption, policy enforcement, audit logging, and secure deployment patterns. AI engineering teams should implement application-level controls, evaluation, and monitoring. Enterprise architects should connect these responsibilities through reference architectures and design standards.

The operating model should define how exceptions, incidents, and changes are handled. It should identify who can approve a new data source, who can authorize a change in AI use, who can grant additional agent permissions, and who can suspend a service when risk conditions are not met.

Training is also important. Users should understand the capabilities and limitations of AI systems, the sensitivity of information they may submit, and the appropriate way to report concerns. Technical teams should understand secure design practices and the organization’s governance requirements.

The objective is to make responsible behavior part of normal delivery and operations. If teams must reconstruct security and privacy expectations for every project, the enterprise will struggle to apply them consistently.

Case study: Meridian Financial Group

18.17 Security, Privacy, and Responsible AI at Meridian Financial Group

Meridian Financial Group is expanding its use of cloud data platforms and AI applications. The organization handles sensitive customer, account, transaction, and financial information across multiple jurisdictions. Its existing security controls are mature in some legacy systems but inconsistent across newer data and AI environments.

Meridian’s first priority is to establish a common view of identities, data assets, processing activities, and trust boundaries. The architecture team works with security and privacy specialists to identify where sensitive information is stored, transformed, shared, and used by analytical and AI applications.

The organization introduces a set of reusable cloud security patterns. These include managed workload identities, least-privilege access, encryption, controlled network connectivity, centralized audit logging, and infrastructure-as-code checks. Data products must identify owners, classification, intended use, and access conditions before publication.

For AI applications, Meridian establishes a standard architecture that separates user interaction, authorization, retrieval, model access, and tool execution. Retrieval services apply access controls before documents are included in model context. Model-generated recommendations are treated as outputs requiring validation, not as authorization decisions.

The first agentic use case supports internal operations by retrieving approved procedures and preparing case summaries. The agent has read-only access to a limited set of sources and cannot directly modify customer records. When an action is needed, the system creates a task for an authorized employee. The architecture records the agent identity, source references, tool calls, and human decision.

Meridian also introduces a use-case risk assessment. Each AI application is evaluated according to purpose, information sensitivity, user population, possible consequences, autonomy, and reversibility. Controls are scaled accordingly. Applications with greater potential impact receive more formal review and stronger oversight.

Privacy requirements are incorporated into data product metadata and AI source registration. Teams must identify the purposes for which personal information may be used and assess whether minimization or transformation is possible. The organization also reviews how retention and deletion requirements apply to derived data and retrieval indexes.

Finally, Meridian establishes production monitoring that connects technical reliability with responsible-use indicators. The organization tracks access failures, unusual tool activity, retrieval behavior, model performance, user feedback, and significant exceptions. Incidents can be investigated using traceable records without treating unrestricted logging as the default.

Meridian’s approach demonstrates that security, privacy, and responsible AI are not separate stages in the project lifecycle. They are connected architectural capabilities that must be designed into information flows, identities, applications, and operating processes.

18.18 Practical Artifact: Security, Privacy, and Responsible AI Architecture Assessment

This assessment can be used during architecture design, solution review, or periodic evaluation of an operational data or AI capability. It is intended to identify architectural gaps and define appropriate controls, not to replace specialist security, privacy, legal, or risk assessments.

Step 1: Define the System and Its Intended Use

Document the business purpose, users, data sources, processing activities, outputs, and actions supported by the system. Identify whether it uses AI and whether its outputs influence consequential decisions.

Step 2: Map Data Flows and Trust Boundaries

Identify where information enters, moves, is transformed, stored, retrieved, or shared. Include internal platforms, external services, model endpoints, logs, caches, derived datasets, and retrieval indexes. Mark the trust boundaries and external dependencies.

Step 3: Identify Identities and Permissions

List human, service, workload, and agent identities. Document authentication, authorization, privileged access, delegated authority, and the permissions available to each identity.

Step 4: Assess Information Sensitivity and Privacy

Identify personal and sensitive information, processing purposes, permitted uses, retention requirements, and relevant restrictions. Determine whether the system can minimize, mask, aggregate, or otherwise transform the information.

Step 5: Review AI-Specific Risks

For AI-enabled systems, examine prompt and retrieval handling, source permissions, model behavior, output validation, tool access, human oversight, and potential misuse. Identify the controls that operate independently of the model.

Step 6: Define Monitoring and Evidence

Determine which security, privacy, operational, and responsible-use events must be monitored. Define the evidence required for investigation, how it will be protected, and the applicable retention approach.

Step 7: Test Failure and Recovery Behavior

Consider compromised credentials, unavailable services, missing data, unexpected model outputs, unauthorized requests, prompt injection, and excessive agent activity. Define how the system detects and responds to each condition.

Step 8: Assign Accountability and Approve the Design

Identify the business owner, data owner, technical owner, security and privacy contacts, and AI risk owner where applicable. Record decisions, unresolved risks, exceptions, and required follow-up actions.

The assessment should result in a prioritized control plan. Each identified gap should have an owner, a target state, and a means of verification. High-impact unresolved risks should be escalated through the organization’s established governance process.

Remember these

Key Takeaways

1. Security, privacy, and responsible AI are architectural responsibilities that must be addressed throughout the data and AI lifecycle.
2. Modern data environments expand the attack surface through distributed platforms, data copies, external services, retrieval systems, model endpoints, and agents.
3. Identity, least privilege, defense in depth, secure defaults, and continuous verification provide important foundations for enterprise security.
4. Privacy engineering translates purpose, minimization, appropriate use, retention, and accountability requirements into practical data and platform designs.
5. Metadata and classification help identify sensitive information, but they become effective controls only when connected to enforcement and operational processes.
6. Generative AI and agentic systems require independent authorization for retrieval and actions. A model should not be treated as the authority for access or execution.
7. Human oversight must be meaningful, supported by evidence, authority, and appropriate workflow design.
8. Responsible AI evaluation should reflect the intended use, affected users, likely failure modes, and consequences of error.
9. Security and privacy controls should be reusable and embedded into platform patterns so that delivery teams can apply them consistently.
10. The Enterprise Data Architect helps connect business purpose, information flows, technical controls, and organizational accountability into a coherent architecture.

Think about your own organization

Architect’s Reflection

Consider an AI-enabled data solution in your organization. Can you identify every place where information enters, moves, is transformed, and is used? Do you know which identities can access it? Are the permissions enforced independently of the AI model? Can you explain what happens when the system retrieves information that the user is not authorized to see, or when an agent attempts an action beyond its approved authority?

Then consider privacy and responsible use. Is the information necessary for the purpose? Are its permitted uses understood? Can users recognize the limitations of the system? Is there a meaningful way to challenge, review, or stop a consequential action?

Security, privacy, and responsible AI are sometimes described as constraints on innovation. A more useful architectural perspective is that they establish the conditions under which innovation can be trusted and sustained. They make it possible for the enterprise to use data and AI without losing control of its information, responsibilities, and decisions.

The architect’s role is not to own every specialist control. It is to ensure that those controls are reflected in the architecture, connected to business requirements, and supported by systems that can demonstrate how they operate.