The Problem

A lot of organizations have Snowflake. Fewer have Cortex enabled. The gap between those two things is almost never technical.

Data teams at financial institutions, government agencies and healthcare organizations watch their counterparts in less regulated industries ship AI features on top of their data platforms and wonder when they get to do the same. The answer, more often than not, is, “Not yet.” Not because Cortex does not work in their environment, but because nobody has worked through what it means to turn it on safely.

The blockers are real. Security teams have not cleared the approval. Legal has questions about data residency and model training. Compliance needs to understand what leaves the environment and what does not. IT needs a deployment architecture that fits within existing access controls. None of these are unreasonable concerns. But without someone who understands both the platform and the governance requirements, they stack up into a wall that stops progress entirely.

We have seen this pattern across financial services, public sector and healthcare organizations. They have invested in Snowflake. They have data worth querying with AI. And they are sitting on Cortex features they cannot use because the path from “We want this” to “This is approved and running” has never been mapped.

What Was Built

InterWorks delivered a production Snowflake Intelligence deployment for a large public sector organization operating under strict government governance requirements, including formal architecture board review, government entry-into-service compliance and data sovereignty obligations. The engagement started as an evaluation of document management options and became a fully operational AI-powered natural language search system running across thousands of technical documents in a government production environment.

The core of the build was a Snowflake Intelligence stack: Cortex Document Intelligence (AI_PARSE_DOCUMENT) extracting structured content from PDF documents sourced from a legacy document management system, Cortex Search indexing the full enriched corpus, and Cortex Analyst and Cortex Agents providing the natural language query layer. Staff who previously had no way to search document content beyond filename metadata can now query the full corpus in plain language.

Before any of that went live, the team worked through a formal government AI assurance process. This required demonstrating to the satisfaction of the relevant oversight body that Snowflake’s AI functions do not train on customer data, that all data remains within the required geographic boundary, and that AI function access is fully governed through role-based access controls. This was the first time the client had put an AI implementation through this process. It is now a documented, navigated pathway.

RBAC governance over AI functions was a technical requirement with commercial dimensions as well: Snowflake AI functions carry per-use costs, so access controls were designed to govern both data access and cost exposure simultaneously.

How It Works

An engagement in this space typically runs in three phases, because the work is as much process as it is technical.

Security and compliance scoping: Before any configuration begins, we map what Cortex actually does with data in the client’s environment. This means working through the specific questions their security team has: Where does the model run, does data leave the Snowflake environment, what are the audit and logging requirements, and how does Cortex interact with their existing row-level and column-level security policies. Most security teams have never seen a clear answer to these questions. Getting them one is usually the thing that unblocks the rest.

Governance architecture: Once security has a clear picture, we design the deployment configuration. This includes defining which Cortex features are enabled for which roles, how network policy and IP allow listing applies, what data can be surfaced through Cortex functions and what stays outside scope, and how the client’s existing data governance framework maps onto Cortex’s permission model. For organizations using Snowflake’s private connectivity options, this step also covers how to route Cortex traffic within those constraints.

Enablement and handoff: Cortex deployed without adoption is just configuration sitting unused. The final phase trains the data and analytics teams on what Cortex can do within their approved configuration, which features are available, and how to build on top of the approved setup without running into the boundaries that took time to establish. The goal is a team that can extend what was built, not just use what they were handed.

Above: The three-phase engagement. Each phase has a distinct character: Phase 1 is process work (getting to approved), phase 2 is technical (building the configuration), phase 3 is people work (making sure the team can use and extend what was built).

How It Was Built

Snowflake Cortex runs within the Snowflake environment, which is the foundational fact that makes it viable for high-control organizations. Unlike many AI integrations that require sending data to an external model endpoint, Cortex functions execute inside Snowflake. Data does not leave the platform to be processed. For organizations with strict data residency requirements or concerns about data exposure, this architecture is the starting point for every compliance conversation.

Above: The data boundary. Staff queries enter the Snowflake environment and answers come out. All Cortex AI processing, data, RBAC controls and network policy sit inside the boundary. Nothing crosses out. This is the diagram that answers the question most security teams have never seen clearly answered.

The specific configuration decisions vary by environment, but the questions are consistent:

Network policy and private connectivity: Organizations with strict egress controls need to understand how Cortex interacts with Snowflake’s network policies. In many high-control environments, Snowflake runs behind private connectivity (AWS PrivateLink, Azure Private Link or similar). Cortex operates within that boundary, but the configuration needs to be explicit. We document the traffic patterns and confirm they fit within the existing network architecture before deployment.

Role and privilege mapping: Cortex functions are accessed through SQL, which means Snowflake’s existing role-based access control applies directly. Designing the privilege structure for Cortex access follows the same principles as any Snowflake access governance work: Least privilege, role hierarchy and explicit grants rather than broad permissions. For organizations that already have a mature Snowflake governance model, this is an extension of existing patterns rather than a new framework.

Audit and observability: High-control environments need to log what happened and prove it to auditors. Snowflake’s query history and access history views cover Cortex function calls the same way they cover any SQL execution. We configure the monitoring and alerting around these logs so the client has the observability their compliance team requires from day one.

SecOps process integration: The technical configuration is only part of the work. Getting Cortex approved often means helping the client’s security operations team understand what they are approving. This includes documentation of the architecture, evidence of how the configuration addresses their specific concerns, and in some cases presenting directly in the security review meeting to answer questions in real time. For organizations that have never approved an AI feature before, this part of the engagement takes as long as the technical work.

A clarification that surfaces in nearly every security review: Snowflake Intelligence components including Cortex Analyst, Cortex Search and Cortex Document Intelligence (AI_PARSE_DOCUMENT) operate on fully managed, fixed AI models. These models do not retrain or fine-tune on customer data, user queries or interaction history. Any improvement in answer quality over time requires intentional, human-directed configuration. Snowflake provides observability and traceability tools to identify where responses need refinement, but the model itself does not learn from client data. This is the answer most security teams have never received clearly, and getting it to them is usually what unblocks the first approval.

In high-control environments, RBAC over AI functions also carries a cost governance dimension: Because Cortex capabilities carry per-use processing costs, access controls define not just who can query sensitive data, but who can trigger AI processing at all.

Why It Matters

The organizations that need this work most are often the ones least likely to find a clear path through it on their own. A financial institution with a capable data engineering team and a thorough security process is not blocked because the people are bad at their jobs. They are blocked because nobody on the team has done this specific thing before, in this specific type of environment, and the cost of getting it wrong is high enough that “wait until we’re sure” is a rational response.

What changes when this work is done is not just that Cortex is on. It is that the organization has a documented, approved architecture for AI on their data platform. That documentation becomes the foundation for the next AI feature, and the one after that. The security review that took weeks the first time takes days the second time because the framework already exists.

The pattern we see most often is that once Cortex is enabled and the first use case is running, requests from the business come quickly. Natural language querying of internal data. Automated summarization of documents that live in Snowflake stages. Anomaly detection on financial or operational data. None of these are possible until the foundational governance work has been done. All of them become straightforward once it has.

Where This Could Go

• Cortex Search and Cortex Document Intelligence in governed environments: Once the base Cortex configuration is approved, enabling Cortex Search for internal document retrieval or Cortex Document Intelligence for unstructured data processing follows the same governance architecture. The hard work of the first approval makes subsequent capabilities faster to deploy.
• Enterprise-wide AI readiness assessment: Organizations that have worked through Cortex governance often discover adjacent questions about their broader AI stack. An assessment of where AI can be applied across the data platform, and what governance gaps exist, is a natural next step.
• Ongoing governance as Snowflake ships new Cortex features: Snowflake releases Cortex features regularly. Organizations that have gone through one approval cycle benefit from a standing review process that evaluates new features against their existing governance framework rather than starting from scratch each time.
• Cross-platform AI governance: The governance principles that apply to Cortex in Snowflake apply to other AI tooling in the stack. Organizations ready to think about AI governance more broadly can use this work as a starting point for a wider framework.
• Training and enablement programs for regulated industries: Data teams in high-control environments need different enablement than their counterparts elsewhere. A training program built specifically for the constraints and requirements of financial services, healthcare or public sector organizations is a gap worth filling.

Takeaway

Most organizations in regulated industries are not waiting for AI to become possible on their data platform. They are waiting for someone to show them how to make it approved. The technical path through Snowflake Cortex in a high-control environment is well-defined. The governance work that has to happen alongside it is where organizations get stuck. Doing both together is the engagement.