Define the data boundary before choosing the model
A common mistake in enterprise AI projects is starting with model capability: can it answer questions, connect to LINE, summarize documents, search ERP records, or update CRM notes? Those are important questions, but they should come after the security architecture. The first engineering question is where data travels, who can access it, how long it is retained, and how deletion or redaction works.
A data boundary is more than a confidentiality label. It has to show up in system design. Does the full user prompt leave the company network? Are retrieved document chunks sent to an external model? Does the vector database store raw text or only embeddings and references? Are chat logs preserving customer data, personal data, attachments, or internal system messages? Is any data used for provider training, analytics, or troubleshooting? These answers shape the architecture and determine whether legal, security, and compliance teams can approve the system.
Not every enterprise needs to self-host models from day one. Managed cloud models often offer better capability, faster delivery, and lower operational load. The trade-off is vendor governance: retention terms, training opt-outs, region, encryption, access controls, incident process, and deletion commitments need to be reviewed as part of the technical design. For sensitive workloads, teams can use masking, retrieval inside the enterprise boundary, private endpoints, summarization before model calls, or self-hosted models for selected flows. The goal is not maximum isolation at any cost. The goal is to match the control level to the data and the business value.
Identity and permissions must follow the user
An AI assistant should not become a shortcut around enterprise permissions. The baseline is simple: the AI must not see more than the user is already allowed to see. This is especially important for RAG systems. Once documents are split, embedded, and stored in a vector index, they can accidentally become a new shared data pool. If permissions are only checked after generation, the model may already have used content that should never have been retrieved.
Treat enterprise AI as a real application, not as a side tool. It needs SSO, role mapping, department boundaries, data ownership, approval workflows, and account deactivation. If the assistant can take action, the control model needs to be even stricter. Reading a customer record, drafting a reply, sending a LINE notification, updating a CRM field, creating an ERP order, and deleting data are different permissions. They should not be bundled into one broad access token.
- User-bound access:Every AI request should run under a real user or scoped service identity, not a shared account that bypasses authorization.
- Pre-retrieval filtering:Apply access rules before searching documents or vectors, not only after the answer is generated.
- Tiered tool rights:Separate read, draft, submit, delete, export, payment, and external notification capabilities.
- Human confirmation:Require approval for sensitive actions such as financial operations, contract changes, customer notifications, bulk exports, and workflow closure.
- Access lifecycle:Account termination, department moves, and role changes must propagate to the AI layer and indexed data.
Prompt injection is a system design issue
Enterprise AI teams need to accept that prompt injection cannot be solved by a better instruction alone. When a model reads documents, web pages, emails, support tickets, API responses, or user-generated content, malicious instructions can be embedded inside the data. The model may be told to ignore rules, reveal hidden instructions, call a tool, change output format, or persuade a user to take an unsafe action. This is not just a prompt-writing problem. It is a consequence of connecting untrusted content to tools and enterprise data.
The model should be treated as a useful but not fully trusted reasoning component. System prompts help, but real controls belong outside the model. Tool calls need allowlists. Parameters need validation. Sensitive fields need masking. High-risk actions need approval. Outputs need policy checks based on context. If an assistant connects to ERP, CRM, databases, ticketing systems, IoT platforms, or internal APIs, the model should not be the only component deciding what is allowed.
A practical architecture splits the flow into layers: input screening, intent classification, retrieval, generation, tool execution, output filtering, and audit logging. Each layer receives only the information it needs and can reject or downgrade a risky request. This adds engineering work and may slow early development, but it prevents the entire security model from depending on one instruction string at the top of a prompt.
Logging and monitoring need privacy by design
AI systems without logs are difficult to operate inside an enterprise. When an answer is wrong, data is exposed, a user takes an unintended action, or a provider behaves unexpectedly, the team needs to reconstruct what happened. Who made the request? Which data sources were retrieved? Which tools were called? What model and configuration were used? Was an approval step completed? Was an external system changed?
At the same time, logs can become a new security problem. If full prompts, document chunks, customer records, personal data, and API responses are copied into observability tools, the organization has created another sensitive data store. Logging must support investigation without casually duplicating everything the AI touched. Decide what to retain, what to mask, what to encrypt, what to store briefly, and who can inspect each level of detail.
A useful compromise is to preserve strong metadata and controlled samples: user identity, source system, document IDs, tool names, risk category, model version, request time, response status, approval outcome, and error codes. Sensitive text can be masked, encrypted, shortened, or isolated behind stricter permissions. If the company already uses SIEM, DLP, KMS, cloud audit logs, or incident response workflows, the AI platform should integrate with those controls instead of building a dashboard that security teams will not monitor.
Turn the baseline into reusable platform controls
Enterprise AI usually starts with one assistant and then spreads into customer service, internal knowledge, operations, sales, procurement, finance, IoT data analysis, and software development. If every project redefines vendor rules, permission logic, logging, masking, review steps, and tool access, risk becomes fragmented. Maintenance also becomes harder because every assistant has its own security assumptions.
A stronger approach is to productize the baseline. Build shared controls for model and API gateways, key management, data classification, RAG authorization, tool invocation policy, approval components, log schemas, vendor review, and launch checklists. Teams can still adapt the experience for each department, but the core security posture stays consistent. This makes new AI workflows faster to launch and easier for security teams to review.
The value of enterprise AI comes from integration, and integration is exactly where risk concentrates. AI becomes sustainable when data boundaries, identity, tool control, observability, and vendor governance are engineered before scale. For organizations connecting AI to cloud platforms, internal systems, LINE workflows, ERP, CRM, and data platforms, an experienced integration team can help turn these rules into repeatable architecture instead of one-off project decisions.