Intelligence belongs where your data already lives.
AI capability is becoming widely available and steadily less expensive. The advantage now sits with the companies that hold a permissioned, reconciled view of their own operations — and keep it under their own control.
The capability layer is becoming a utility.
Frontier model capability arrives faster each quarter, from a widening field of providers, at prices that fall on a schedule that would have seemed implausible two years ago. Enterprise platforms increasingly route work across several models at once, selecting by cost, speed, or task. Openly published model weights now sit within reach of the leading commercial systems.
Each of these developments points the same direction. Raw intelligence is becoming abundant, substitutable, and cheap. Whichever model performs best this quarter has a short window before another one does, and the cost of moving between them keeps falling.
The strategic consequence follows directly: an AI strategy that rests on access to a particular model rests on ground that shifts every few months.
The durable advantage moves to governed context.
A model reasons only as well as the record it is permitted to read.
This is visible in the direction the entire industry has taken. The significant engineering investment across the market has moved away from raw capability and toward grounding: connecting models to analytical data, giving agents shared memory, building gateways that determine what an agent may reach, and creating audit layers that record what it saw. Every one of those investments is an acknowledgment that the model is the straightforward part, and the demanding part is a trustworthy, permissioned, connected view of the business for the model to work from.
Manufacturers, representative firms, and distributors understand this from experience. A forecast earns confidence through the reconciliation between field demand, backlog, point-of-sale actuals, inventory, and shipments. A quote holds margin because pricing floors, minimums, and approvals are enforced at the moment it is built. A debit clears because the claim, the price protection agreement, and the channel inventory position agree with one another.
That reconciliation is the asset. Intelligence is a tool applied to it — and the tool is now available to everyone.
Your operating data carries contractual boundaries.
For this industry, the case for control rests on obligations you have already signed rather than on general principle.
A design-win registration reveals a customer's product roadmap, typically under a non-disclosure agreement. Distributor point-of-sale and debit data arrives under terms that specify who may see it and for what purpose. A representative firm holds forecast and account data for principals who compete with one another, inside one system, separated by permission. Pricing floors, minimums, and contract terms represent the most closely held commercial information a manufacturer owns.
These disclosure boundaries were written into agreements with other companies. Those agreements describe your organization, your named users, and your systems. Extending them to cover processing inside a third-party model runtime is a question that deserves a deliberate answer, given by the people who signed them.
The direction of travel is the decision.
Two architectures are available. In the first, operating data travels outward to a model provider's runtime, and controls are added at the boundary to record and constrain the journey. In the second, the model is applied to data that remains inside the organization's own perimeter, governed by permissions the organization already maintains.
Both approaches can be operated responsibly. The difference lies in what each treats as the default and what each requires you to actively manage. The first asks you to track a provider's terms, subprocessor list, default settings, and regional availability on a continuing basis, because those elements are maintained by someone else and revised on their schedule. The second keeps the surface area small enough that a security review can describe it completely.
NEHANET's default is the second: the model comes to your data, under your permissions.
What that means in practice.
Four commitments carry this position from principle into architecture.
Deployment is your decision.
NEHANET runs hosted or on your own infrastructure — the same application, the same modules, the same 52 capabilities either way. On-premises deployment places the application on a customer-operated Windows server-class machine with Microsoft SQL Server, inside your data center. Installation and support access are governed by your policy, with the authorization method, logging, time limits, and revocation confirmed together before go-live.
Permissions are the operating model.
Access is governed by company, role, region, business unit, team, and partner relationship, and further by module, action, and record scope. Any process operating inside NEHANET inherits those boundaries. As enterprise platforms open every capability to authenticated callers, this distinction grows more consequential: the identity reading a record determines what that record shows, whether the caller is a person or a process.
Intelligence works from authorized context and leaves evidence.
NN AI plans and verifies multi-step analysis across authorized CRM, ERP, SQL, report, document, and workflow context. It retains evidence, verifies numerical claims, and requires approval before taking action. It remains a separate, optional product, while the CRM stays the system of record. When it produces a number, the path to that number is traceable.
Model portability is a design constraint.
Because the capability layer is commoditizing, we architect deliberately for independence from any single provider's runtime, pricing, or roadmap. This is the practical application of the first principle on this page: value that rests on a specific model has a short life, so we place value in the layer that endures.
A clear view of what each choice delivers.
We hold a precise position on the trade-offs, and we prefer to state it plainly.
Frontier-scale models offer remarkable raw capability, and they perform that way inside large accelerator clusters operated at scale. Openly published weights deliver genuine structural benefits — auditability, pricing discipline across the market, and freedom from unilateral revocation — while serving the largest of them still calls for substantial infrastructure. An organization choosing to run models within its own perimeter makes a considered trade: a defined capability envelope in exchange for a defined and provable data boundary.
For the work that moves an operating number, that trade favors control. Reconciling a forecast against backlog and channel actuals, surfacing a quote that breaches a pricing floor, identifying debit claims that will require intervention, and finding the plan gap in time to act on it — this work rewards correct, permissioned, connected data and a system that shows its reasoning. It rests on the quality of the record far more than on the scale of the model.
That is the problem we have built for this industry, and it is the one where governed context compounds year over year.
Questions worth bringing to any AI evaluation.
These apply to every vendor under consideration, including us. We are glad to answer all five in writing.
Where does inference occur, and under whose legal jurisdiction?
Storage residency and processing residency are separate questions, and both belong in the answer.
Which identities can reach which records?
Ask for the list of authenticated callers, human and automated, and the permission scope each one holds.
What evidence survives the interaction?
A produced number should carry a traceable path to its sources, retained for audit.
What remains constant when the underlying model changes?
Portability determines whether a provider's roadmap decision becomes your migration project.
How do your signed agreements read against this architecture?
Test the deployment against your principal, distributor, and customer contracts as written.
Bring these questions to your own environment.
A deployment and security review produces a responsibility matrix, current requirements, a data-flow diagram, an access model, integration controls, a backup and recovery plan, and the trust documentation your team needs — completed before commercial scope is finalized.