How to work within enterprise security constraints, connect AI systems to legacy infrastructure, and handle customer data responsibly - without stalling the engagement.
✍️ AI School Editorial Team · Lilly Tech Systems📅 Published Jul 2, 2026 · Reviewed Jul 2, 2026
The Customer Environment Is Not Your Lab
In your own development environment, you have root access, no firewall, full control of every dependency, and the freedom to spin up any service you need. Customer environments have none of these properties. They have IT approval processes, data classification policies, network egress restrictions, legacy systems that have not been touched in a decade, and legal agreements that constrain where data can travel.
Most FDAE integration failures are not technical failures - they are failures to understand the constraints early enough. The system that worked perfectly in your local environment breaks on the customer site because their network does not allow outbound calls to the LLM API, or because the data you need is stored in a format their IT team will not export, or because the tool you picked requires a cloud account and their security team has not approved cloud storage for this data class.
The fix is to ask about constraints in discovery, not after you have built the prototype. A single question during the discovery session - “What are the constraints on where this data can travel?” - can save two days of re-architecture at the integration stage.
The Read-Only First Principle
When integrating into a customer environment for the first time, start with read-only access. Read-only access is easier to obtain, carries no risk of data modification, and allows you to build and validate the AI system before requesting elevated permissions. Escalate from read-only only when you have a working prototype and a clear reason to write.
In practice, the integration permissions required at each stage of a FDAE engagement scale predictably:
Stage
Access level
Risk
What you need
Prototype
Read-only sample data export
Low
A CSV or JSON export of 50-200 representative rows
Pilot
Read + write to staging environment
Medium
A staging database or shadow workflow that mirrors production
Production
Scoped write to specific tables or queues
High
Minimal permission set, audit logging enabled, rollback plan
✅
Ask for the minimum: Request the specific tables, fields, or endpoints you need, not admin access. IT security teams approve narrow requests faster and with less scrutiny. You can always request more access later; asking for admin credentials on day one signals poor judgment.
Working Within Security Constraints
Enterprise security constraints are not obstacles - they are the real environment you are building for. Designing around them rather than against them is part of the FDAE job. The most common security requirements you will encounter:
1
No customer data leaves the corporate network without approval. If the LLM API is external (e.g. Anthropic, OpenAI), you will need the customer’s InfoSec team to approve the API endpoint and the data classification. Build time for this approval into the engagement plan, or prepare an alternative: a locally-hosted model, or a data anonymization step before external API calls.
2
All API endpoints must be on an allowlist. Some enterprise networks block all outbound traffic except pre-approved domains. The LLM provider’s API domain, any external vector database, and any dependency your prototype downloads at runtime must all be explicitly allowlisted. Test from inside the network on day one, not at demo time.
3
Audit logging is often required. Enterprise compliance frameworks frequently require a log of every external API call, including what data was sent. Build logging into your prototype from the start. A logging wrapper around your LLM calls costs an hour to add and can unblock the engagement entirely when security review asks for it.
4
No external storage for customer data without a DPA. Storing customer data in a cloud vector database, a hosted spreadsheet, or a third-party analytics service requires a signed Data Processing Agreement. Check whether the customer has existing DPAs with the services you want to use before you build the architecture around them.
Handling Customer Data With LLMs Safely
Sending customer data to an LLM API creates obligations that the FDAE cannot ignore. Even if the customer seems comfortable with it, the FDAE is responsible for making the risks explicit and designing defensively. Three questions to answer before any customer data reaches the model:
⚠️
Training data opt-out: The major LLM providers offer enterprise API tiers that exclude customer data from training. Confirm this is configured before the first production call. If the customer does not have an enterprise agreement, data sent via the standard API tier may be used for model improvement depending on provider terms. This is a conversation to have with the customer’s legal team, not a decision you make on their behalf.
⚠️
PII classification: Identify whether the data contains personally identifiable information before it enters the pipeline. If it does, determine whether the use case requires PII to be present, or whether a pseudonymization step (replacing names, account numbers, and other identifiers with placeholders before the LLM call) is viable. Pseudonymization reduces compliance risk and often has no effect on model output quality for classification and summarization tasks.
A practical pattern: build a preprocessing step into the pipeline that logs what data categories are present in each input batch. This gives the customer’s security team visibility into what the system is handling and provides a defensible record if questions arise later.
Legacy System Integration Patterns
Most enterprise customer data does not live in a clean REST API. It lives in an ERP system from 2009, a shared network drive with inconsistent naming, an email inbox that functions as a workflow queue, or a database schema designed before the business understood its own processes. Three patterns that handle the majority of legacy integration cases:
📚
Pattern 1 - Document export: The system cannot be queried directly, but it can produce reports. Have the customer generate a scheduled export (daily CSV, nightly PDF batch, weekly Excel summary) and point your pipeline at the export directory. This works with almost any legacy system, requires no API integration, and puts the data refresh rate in the customer’s control. Limitation: latency is tied to export frequency. Not suitable for real-time use cases.
📚
Pattern 2 - Email-in / email-out: Many legacy workflows already use email as the integration layer. An AI pipeline that reads from a specific inbox and writes results back to the same thread slots into existing workflows without touching the legacy system at all. This is particularly effective for document review, approval routing, and customer inquiry triage. Build with a dedicated service inbox, not a personal account.
📚
Pattern 3 - Browser automation as last resort: When a system has no export capability and no API, browser automation (Playwright, Selenium) can extract data by navigating the UI. This is fragile - UI changes break it, and it may violate the vendor’s terms of service. Use only when no other option exists, document the fragility explicitly, and plan the migration path to a proper API integration in the production phase.
💡
Integration documentation: Every integration point - export schedule, email inbox, API endpoint, database connection - should be documented in the handoff package with the owner, the failure mode, and the recovery procedure. Integration points are the most common place where things break after you leave. See Lesson 7: Deployment, Monitoring, and Knowledge Transfer for the full handoff documentation standard.