For ANCSA regional and village corporations
Alaska Native corporations carry shareholder records, land records, and subsidiary financials that should not be handed to a vendor’s cloud on a promise. We build AI that runs inside infrastructure you control, and we scope what will not be automated before anything is built.
Built in Anchorage · we publish our source code · no long-term lock-in
Written by Kristian Baer, Northtek · Anchorage, Alaska · Updated 2026-08-21
The short answer
Yes, but only if the architecture is chosen for that from the start. The default path - a subscription to a vendor platform - means shareholder records, land documents, and subsidiary financials leave your control and sit under someone else’s terms of service. The alternative is to run the model and the memory layer inside infrastructure the corporation owns or leases directly, so the records never leave a boundary your board approved. We build offline and tenant-resident memory infrastructure as part of our own research, so this is a configuration decision rather than a custom project. The practical steps are the same either way: name every system that will touch the data, put no-training and custody terms in the contract, keep a citation on every generated answer, and write down which record types are out of scope entirely before development starts.
The operating reality
Few structures anywhere combine this range of obligations: fiduciary duty to shareholders, consolidated reporting across subsidiaries on different systems, land and records responsibilities dating to ANCSA, and in many cases a federal contracting arm with its own compliance regime.
A construction subsidiary, a services subsidiary, and a federal contracting subsidiary often run different ERPs and report in different formats. Building the board package is a monthly reformatting exercise.
Enrollment, dividends and distributions, address changes, descendant questions, and proxy season all arrive at one desk. The volume is administrative. The tone requirement is not.
Conveyance documents, easements, resolutions, and correspondence span paper, microfilm, scans, and modern systems. Answering a land question can take days.
A subsidiary in the 8(a) program or holding federal contracts carries requirements - including handling of controlled unclassified information - that constrain which tools may touch which documents.
Six workflows we build
Ordered so the lowest-sensitivity workflow proves the approach before anything touches shareholder records.
01
02
03
04
05
06
First 30 days
It is high-effort, entirely internal, and touches no shareholder record. You get to evaluate how we work on financial data before deciding whether we ever touch anything more sensitive.
Before any development, we produce a written architecture: where the model runs, where the data rests, who can access it, what is logged, and which record types are out of scope. Your board or IT committee approves that document before we write code.
We normalize and consolidate a quarter you have already closed, then compare our output line by line to the package your controller produced. Differences get explained, not smoothed over.
The agent produces the package alongside your existing process for one full reporting cycle. Nothing depends on it until your controller says it should.
What you own at day 30
A consolidation agent running inside infrastructure you control, a line-by-line reconciliation against a package your own team produced, an approved data governance document, the repository and configuration under your ownership, and a written list of the record types we agreed we would not touch.
What we built, in the open
Every serious conversation a corporation has about AI ends at the same question: where do the records physically live. Firms that assemble products from third-party services cannot answer it, because the answer is set by a vendor they do not control. We build the memory layer ourselves, which is what makes a different answer possible.
An offline memory server we wrote and benchmarked in public against a commercial competitor. Because it is ours, a deployment that never leaves your tenant is a configuration choice rather than a special engineering project with a special price.
A language and compiler built so an agent's actions are auditable line by line - the property your IT staff and your auditors will actually ask about.
A verification gate that requires a generated answer to be supported by a source record. Applied to shareholder correspondence, it is the difference between a drafted reply and a plausible one.
We publish all of it with its commit history. For an organization with fiduciary duties, a vendor claim you can independently verify is worth more than one you cannot.
Scope, stated up front
For an organization with fiduciary duties, the boundaries matter more than the capabilities. Three decisions that stay entirely with your people.
We do not claim cultural expertise
We build software. Decisions about what is culturally appropriate to digitize, index, or automate belong to your people and your board, and we will build the boundary you set rather than propose one.
It does not decide eligibility or benefits
Enrollment, distributions, estates, and benefit determinations are consequential and personal. The agent prepares files. Staff decide, every time, and we will not build it otherwise.
It gives no voting or investment advice
During proxy season it answers procedural questions only, from your published materials. It will not characterize a resolution, and it will not be built to.
Where your data goes
Governance comes before features here. Five commitments that go into the agreement your board reads, not into a slide.
No. That is a contract term, not a policy page, and it applies to us and to every provider in the chain. Where the risk cannot be eliminated by contract alone, we run the workload inside your own infrastructure so the question does not arise. If any component in a proposed design cannot meet that standard, we tell you which one and what it would take to replace it.
Yes. We build offline memory infrastructure as part of our own research, so a fully tenant-resident or air-gapped deployment is a configuration choice rather than a custom engineering effort. We will show your IT staff exactly where each component runs and let them verify it.
By not deciding. We ask which record classes are excluded and we build that exclusion into the system so it is enforced technically rather than by policy memory. If your board has not made that determination yet, that is a reason to make it before the project starts, not a reason to start without it.
That is exactly the case this handles well, because the work is mechanical rather than judgment-based. We read whatever each subsidiary produces - exports, PDFs, spreadsheets, or an ERP API - and normalize it. We do not ask you to standardize the subsidiaries first, which is a multi-year project that usually stalls.
The corporation does. Code, configuration, prompts, and data. We hand over the repository and train your IT staff to run it. There is no platform fee, no hosting dependency on us, and nothing that makes leaving expensive. That matters more for an entity with fiduciary duties than for anyone else on this site.
They should, and we build expecting it. Source code is available to them, every generated answer keeps a citation to its source record, and access is logged. If your internal audit or an external auditor wants to trace how an answer was produced, that path exists by design rather than being reconstructed after a question is raised.
No, and you should be sceptical of anyone who says it does. A partner running your Dynamics, Azure, and Microsoft 365 estate is doing platform work: licensing, identity, integration, uptime. What we build is the agent layer that reads your documents and writes into those systems, and it is a different discipline with different failure modes. In practice we read from and write into whatever your partner maintains, and the two roles do not overlap. If a firm proposes replacing a working platform estate in order to add AI on top of it, that is a scope problem rather than a strategy.
A readiness assessment produces a document. What we do produces a working automation inside a system your team already uses, usually within about 30 days, and the assessment happens as a by-product of building the first one. Assessments are genuinely useful when an organisation has no idea where to start; if you can already name the workflow that is eating the most hours, paying for a document that names it back to you is an expensive way to reach the same place.
Government Contracting
Solicitation triage, compliance matrices, and past performance for federal subsidiaries.
Read →
Tribal Governments
Grant discovery, reporting, and member services for tribes and consortia.
Read →
Construction & Contractors
Project documentation for construction and heavy civil subsidiaries.
Read →
We will write the architecture down, name every system that would touch your records, and let your board read it before anyone talks about a build.
Anchorage, Alaska · info@northtek.io · (907) 903-4353