Implementation
The Problem
Your security team isn't wrong to say no. An AI tool with unrestricted access to production data is a real risk. The answer isn't to argue with security. It's to give security what they need to say yes.
Field-level control. Enforced at the architecture level.
Enterprise databases are built for applications, not for AI. Field names like cst_stat_cd and plcy_eff_dtare technically readable, but without business context, AI fills in the gaps on its own. That's where hallucinations start, and without the right foundation, they compound fast.
Give AI the context to use your data accurately.
The Approach
Priority systems and roles launch first. The rest keeps building in parallel.
Priority Roles
First 1–2 departments
Govern
Enrich
Assign
Deploy
Expansion Roles
Next departments
Govern
Enrich
Assign
Deploy
Remaining Roles
Full coverage
Govern
Enrich
Assign
Deploy
findings feed back into the Data Map
The Work
Four things have to be right before a deployment goes live. Each one directly affects whether AI works accurately and safely in your environment.
Before access can be configured, someone has to map what's there. Tables, fields, relationships, and what each one means to the business. Some systems are well-documented. Most are not.
We start with the systems your priority roles touch. The rest follows.
We map the tables and fields your highest-value roles need first. Incomplete documentation and legacy schemas are the norm, not the exception. This process is built for that.
Your data doesn't need to be clean. It needs to be mapped and described. ArcMantis makes this manageable.
Raw database field names like adj_bal or stat_cd give AI models just enough to guess. In a regulated environment, guessing is the problem. Wrong answers that look right are the most dangerous kind.
Enrichment translates every table, field, relationship, and valid value into business-meaningful metadata the AI can reason with.
Each layer of context reduces the room for error.
CorralData, 2025. Per-component accuracy improvement vs. no-metadata baseline (GPT-4o, 2,432 test runs). Consistent with Atlan 2026 findings (38% overall improvement, p < 0.0001, 522 queries).
This is the highest-return work in any implementation. It runs in parallel with mapping and keeps improving as real usage reveals gaps.
Every role has a different relationship with data. A role might touch a single system, or it might span several, giving someone a governed view across systems they currently access independently.
Role identification is not only about drawing access boundaries. It is also about understanding what each role does, where AI adds value, and what access that requires.
Without role-level isolation, a regional manager's AI assistant can surface accounts from other regions. A department head's tool can pull compensation data from HR. These are not hacking scenarios. They are default configurations.
IBM Cost of a Data Breach Report, 2025
Real users running real queries surface what configuration alone cannot: fields where a description needs to be reworded for how people actually ask questions, status codes that need enumeration, relationships that weren't obvious in the schema.
This is where we fine-tune the metadata based on AI response quality.
Real queries from real users show where descriptions, enums, or relationships need adjustment.
Configuration sets the rules. Testing proves they work.
The Outcome
A governed endpoint for each configured role. Enriched AI metadata, validated access boundaries, and a complete audit trail.
Every table and field mapped, classified, and access-controlled. Hidden means hidden. No role, no user, no agent can surface it.
Business names. Plain-language descriptions. Valid values. Cross-system relationship annotations. Written for every table and field your roles can see.
One governed connection per role. Field-level filtering, identity validation, and logging on every request. Your security team can approve it.
Who sees what, across every system and every role. Documented, validated with stakeholders, ready for compliance review.
Everything that comes after builds on this foundation. Additional roles, additional systems, agentic workflows.
The Process
Before a contract is signed, we run a systems assessment.
This is working time. Not a sales call.
We assess every system you want to connect: structure, ownership, connector availability, and documentation quality.
We work with you to identify which roles will benefit most from AI access and where the return will be clearest. Not every role is equal. We start where the value is highest.
A high implementation cost needs to be justified by a real result.
The assessment produces two things.
First, a prioritized AI readiness picture for your environment. Which systems are candidates for AI connection, which roles have the clearest ROI case, where the data complexity and risk actually sits, and what getting this right will realistically require from your side.
Second, a scoped implementation proposal: timeline, cost, and sequencing based on what we found.
You own the readiness picture regardless of next steps. Most organizations find it useful internally before any vendor decision is made.
At Runtime
No matter which AI tool sends the request, every interaction passes through the same enforcement chain.
Implementation starts with understanding your systems. We'll map what you're working with, validate your priorities, and give you a clear scope, along with a prioritized AI readiness picture for your environment that's yours to keep, regardless of next steps.