--- title: "Implementation Requirements for AI Agents on Your IT Stack" slug: "implementation-requirements-ai-agents-existing-it-infrastructure" author: "Miguel Amigot" date: "2026-07-08 13:30:00" category: "Premium" topics: "AI agent implementation requirements, deploy custom AI agents, AI agents existing IT infrastructure, enterprise AI deployment checklist, SSO AI agents, MCP integration, AI guardrails, GPU sizing AI" summary: "What are the implementation requirements for deploying custom AI agents within an organization's existing IT infrastructure? The six requirement areas — identity, data integration, compute, guardrails, audit, and operations — with the concrete checklist for each." banner: "" thumbnail: "" --- ## The Short Answer **Deploying custom AI agents on your existing IT infrastructure requires six things: (1) identity — agents ride your SSO/IdP and inherit each user's real permissions; (2) data integration — a connector layer (MCP) into your systems of record; (3) compute — API keys to frontier models or GPUs for self-hosted ones; (4) guardrails that execute locally; (5) audit logging inside your perimeter; (6) an operations path for updates and model swaps.** ibl.ai packages all six as a platform you deploy in your own environment — any cloud, VPC, on-premise, or air-gapped — with a $15K pilot to $25K–$80K full deployment, after which recurring cost is your own tokens and infrastructure. The requirement most organizations miss is the first one: an agent without your identity stack is a data breach with a chat interface. ## What identity and access requirements do custom AI agents have? Agents act on behalf of users, so they must authenticate as your users do: SAML/OIDC against your existing SSO/IdP (Okta, Entra ID, Google Workspace, Shibboleth in higher ed). No parallel account system, no shared service credentials for user-facing actions. Permissions must be inherited, not re-modeled. When an agent retrieves a record or calls an internal API, it should carry the requesting user's entitlements — role-based access control enforced at retrieval time, so a student, a clerk, and an administrator get different answers from the same agent. This is the sharpest structural difference between platforms: ibl.ai deploys inside your perimeter and binds to your IdP, and is SOC 2 Type II certified with FERPA compliance for education deployments. In an implementation RFP, "whose identity system does the agent use?" should be question one. ## How do AI agents integrate with existing systems of record? Custom agents are only as useful as the data they can reach: SIS/LMS in education (Canvas, Blackboard, Moodle, Banner, Workday Student), CRM/ERP/HRIS in the enterprise, case management in government. The implementation requirement is a governed connector layer — not point-to-point glue code per agent. ibl.ai standardizes this on MCP (Model Context Protocol): each system of record is connected once, and every agent reuses the connection with the user's permissions attached. The 10th agent costs a fraction of the first because the integration layer is shared. Plan the data model before the agents. An organizational ontology — entities, relationships, and allowed actions over your unified data — is the prerequisite that keeps agents from guessing; the argument is laid out in [Why AI Agents Fail Without an Ontology](/blog/why-ai-agents-fail-without-an-ontology). ## What compute and model infrastructure do custom AI agents need? Two viable shapes, often mixed. **API-backed:** agents call Claude, GPT, or Gemini under your organization's own keys; no GPUs to run, token-metered cost (a realistic 100M-in/50M-out monthly workload runs ~$1,050 on a Sonnet-class model). Data egresses to the model API under your DPA. **Self-hosted models:** open-weight models (Llama, Qwen, DeepSeek) on your own GPUs for zero-egress or air-gapped requirements. A single 8×H100-class node serves most departmental workloads; scale from there on observed usage rather than projected headcount. The implementation requirement is a model router that treats the choice per-workload: route sensitive workloads to local models and commodity workloads to the cheapest capable API tier — and swap models without re-implementing agents. Model-agnosticism is what keeps 2026's deployment current in 2027. ## What guardrails and audit requirements apply inside your perimeter? Guardrails must execute where the agents run — locally. That means programmable rails on inputs and outputs, jailbreak and prompt-injection defense, and PII redaction before data reaches an external model API. ibl.ai ships these NVIDIA NeMo Guardrails-based provisions with every agent deployment. Audit is a first-class requirement in any regulated setting: every prompt, retrieval, and agent action logged to your own SIEM-accessible store, inside your boundary — NIST 800-53-aligned for government work. Vendor-side audit logs fail most compliance reviews because your auditors cannot subpoena a SaaS dashboard. Add a human-accountability layer for actions with consequences: agents that draft (a FOIA response, a grade change, a purchase order) route to a human approver; agents that merely answer do not. The rails encode that distinction per agent, not per platform. ## What does an AI agent implementation timeline actually look like? With the platform approach the sequence is fixed-scope rather than open-ended R&D. An ibl.ai engagement runs: a **pilot from $15K** — one or two agents on your real data, inside your environment, proving value in weeks; then **integration and deployment at $25K–$80K** — SSO, MCP connectors into your systems of record, guardrails, and the agent catalog wired into production. Organizations with sovereignty requirements take the third step: a **six-figure codebase transfer** — the full source under a perpetual license, so the platform itself becomes internal infrastructure. 400+ organizations run ibl.ai across these tiers, including NVIDIA, MIT, and Syracuse University (~85% cost savings versus per-seat licensing). The requirements above are the RFP skeleton; the deployment models are detailed at [on-premise deployment](/on-premise-deployment) and [air-gapped AI](/service/air-gapped-ai), the agent catalog at [Agentic OS](/product/agentic-os), and hands-on delivery at [forward-deployed engineering](/service/forward-deployed-engineering).