On August 6, 2026, our founder Lorenzo Chu presented “Start With Less Data” at the TEDNA Native Futures webinar — a session for Tribal Education Departments weighing AI tools for student, family, and community services. The material below is the part worth keeping: a ten-question review you can take into a vendor meeting, and what we found when we ran the same questions at our own community app the night before the talk.
The first question is not “what can it do?”
Almost every AI pitch opens with capability. Capability is the easy half, and it gets cheaper every month. The question that actually determines your risk is different: what data must you give up to get the value? Ask that first, then decide whether the trade is worth it.
Sort the use case before you evaluate the vendor
Not every AI use carries the same stakes, and sorting them takes about a minute:
- Find — public information, deadlines, services. Low stakes; the worst case is usually an inconvenience.
- Support — summarizing, drafting, helping someone navigate a process. A person still decides, but the tool is shaping how they see it.
- Decide — eligibility, funding, student support. The output changes what happens to a real person.
The farther along that line a proposal sits, the more authority and oversight it needs. A surprising number of pilots are quietly in the third column — attendance flags, eligibility screens, risk scores — while being sold as the first. Name the column before you approve anything.
What we found running these questions at our own product
OlenHub is our community information app for the eight North Slope villages — no login, no account, public information only. Before the talk we tested it against the same questions we were about to hand the audience. Four things worth reporting:
- Collecting less is the hard engineering. Of 4,935 candidate events extracted from public sources, 3,760 were rejected. The system throws away far more than it publishes, and that filter is most of the work.
- Guardrails in code and guardrails in a prompt are not the same thing. Across 30 live production calls, the assistant fabricated zero contact details — because phone numbers and source links are rebuilt in code from what was actually retrieved, so the model cannot invent them. But whether it says “I don’t know” out loud is model judgment: it declined appropriately in 20 of 24 cases. One run answered a question about a future school closure with confidence it had no basis for. Ask a vendor which of their guardrails is enforced in code and which depends on a prompt.
- A citation does not prove correctness. We found three different phone numbers for the same store across our own data files. Whichever one won retrieval is what a resident was told. Every one of them was a real, openable source; at most one was right. Conflict resolution is a governance question, not a search feature.
- A no-login screen can still carry governance debt. We collect no name, email, or account, and commenter names are stripped before anything reaches a model or a screen. But to build the calendar we read public community posts, and the replies arrive with names attached — 1,856 distinct ones sat in raw storage, with no retention period and no resident deletion path. Privacy-friendly design is not the same as a complete data lifecycle.
The ten questions
Use these as a first gate — not a complete governance framework, and not a substitute for your Nation’s own data policies.
- Authority and purpose Who defines and approves the purpose? Who may approve a change in purpose?
- Minimum data What is the least data required? Ask the vendor to justify every category.
- Identity Does the task truly need a name, account, student ID, or permanent profile?
- Sources and freshness Can users open the source, identify its authority, and see when it was verified?
- Access and reuse Who can process or reuse data, including vendors and subprocessors? Is it used for training?
- Uncertainty What happens when information is missing, stale, contradictory, or outside scope?
- Decision rights Which decisions remain with authorized people? Can they correct, disagree, and appeal?
- Real-world access Does the full workflow work on phones, weak connections, shared devices, and without an account?
- Lifecycle Can data be corrected, exported, deleted, and assigned a specific retention period?
- Exit How can the Tribe stop the pilot or leave the vendor? What is returned, deleted, or left behind?
A note on CARE, and on authority
The CARE Principles — Collective Benefit, Authority to Control, Responsibility, Ethics — are a useful lens for these conversations. They are not a certificate a vendor issues to itself. If a vendor tells you they are “CARE-compliant,” that is a good moment to slow the meeting down and ask who assessed it and against what.
OlenHub is a public-information tool, not a data-governance system, and we do not claim CARE compliance for it. A governance system needs approved purpose, access rules, retention, correction, deletion, vendor and subprocessor rules, audit, exit, and named accountability. Deciding what Tribal data sovereignty requires is not ours to define — that authority belongs to each Tribal Nation and the people and institutions it designates. What we can offer is the vantage point of a team that made these decisions and then went looking for where its own were wrong.
Where to start
Start small. Collect less. Make the pilot reversible — if you cannot stop it and get your data back, it is not a pilot. And keep people accountable for the decisions that matter.
If your department is weighing a specific tool or pilot and wants a second read on it, get in touch.