Why No AI First Is a Governance Strategy

I led an institutional operations team building a project and knowledge management system for work that involved projects, policies, records, datasets, events, approvals, staff activity, and long-lived organizational memory. The obvious product pressure was to add AI early: chat over documents, summarize meetings, generate handover packs, score risks, and make search feel intelligent.

I championed the opposite sequence and nudged the team towards it. I set the first-release direction: exclude LLM features, semantic search, AI summaries, AI drafting, AI scoring, and AI capture. The product first had to show that records, permissions, lifecycle states, and search behavior were trustworthy without a model in the loop.

That was not an anti-AI position. It was a governance strategy.

The product needed to replace scattered folders, informal handovers, manual status chasing, and inconsistent institutional memory. Staff needed one operating layer for project facts, workflow state, controlled documents, knowledge assets, policy versions, events, budgets, decisions, datasets, risks, issues, and records.

In that environment, an early assistant would have been risky. A model can make disorder easier to consume, but it cannot decide which document is authoritative, which user may see a private asset, whether a draft has become a declared record, or how long a record must be retained.

The system needed governed facts before generated answers. That meant stable identifiers, lifecycle rules, deterministic search, explicit permissions, audit trails, and manual capture paths came first.

The hard constraint was institutional trust. Users would rely on the system for work that needed traceability, permission control, and record discipline. If the product could not distinguish a draft from a final approved version, an internal asset from a public one, or a project-team document from a private owner-only asset, AI would amplify the confusion.

The future AI layer also had to inherit the same controls as the rest of the application. It could not become a parallel retrieval product with broader access, weaker retention behavior, or uncited summaries detached from source records.

I used that constraint to shape the MVP. The first-release scope included authentication, role-based access control, a staff portal, a project registry, project lifecycle gates, knowledge assets, policy versioning, workflows, dashboards, deterministic search, notifications, audit logs, and basic reporting exports. It explicitly excluded AI chat, semantic search, AI-generated meeting minutes, AI metadata extraction, AI drafting, AI risk scoring, and AI handover packs.

I set the architecture around authoritative objects rather than prompts. From there, we linked project-bound material to a stable project identifier and non-project institutional material to controlled containers such as governance, onboarding, or internal knowledge spaces.

That gave the product a spine. Project names, owners, partners, stages, and donors can change. A stable identifier lets documents, decisions, events, tasks, datasets, risks, issues, and records stay attached to the same institutional object over time.

I directed the team to separate three concerns:

• The system of record held official facts about projects and operating objects.
• The system of work turned policy into approvals, tasks, stage gates, onboarding, travel, procurement, publication, and closure flows.
• The knowledge and records layer managed controlled policies, datasets, minutes, outputs, communications assets, training material, evidence packs, archives, and disposed records.

That separation gave the product useful answers before it had an assistant. It could answer operational questions from stored facts: who owns this project, what stage is it in, which policy version applies, whether required records exist, and which assets are approved.

I used the search design to make the "No AI first" principle concrete. I steered the team towards keyword and faceted search across known entity types rather than vector retrieval or generated answer synthesis.

Before building queries, the system resolved what the viewer was allowed to search. Attribute-based access control mapped effective permissions into searchable entity types. Users with broad administrative or wildcard capabilities could search all configured types. Other users received only the entity types represented by their permission set.

Search then queried only allowed entity types. It did not query everything and filter late. That detail matters because it makes the permission boundary part of the retrieval plan rather than a cleanup step after results are collected.

The object-level rules were also explicit. Public and organization-visible assets could be available to staff. Project-team visibility required active project membership. Private visibility required ownership. Draft and in-review material stayed out of normal search results until it reached the right lifecycle state.

Records management used the same approach. Knowledge assets carried asset type, owner, lifecycle state, visibility, retention class, version information, source metadata, review notes, approval metadata, declaration metadata, archive metadata, disposition metadata, and actor timestamps.

Lifecycle states were not loose labels. Draft, in review, approved, final approved version, declared record, archived, and disposed represented different governance positions. Database constraints enforced important transitions. A declared record required retention information. Archived, declared, and disposed records required actor and timestamp metadata. Disposed records required a disposition log.

That structure gives a future AI layer something safer to retrieve from. An assistant can later ask for final approved versions or declared records instead of treating every uploaded draft as equivalent evidence.

The first tradeoff was product restraint. AI features are visible and attractive. Governance work is less flashy, but it determines whether later AI can be trusted. I set the priority: the team would define a governed operating layer before adding probabilistic interfaces.

The second tradeoff was deterministic integration capture. I kept the MVP focused on explicit references and metadata linked to governed records instead of live email, chat, and calendar sync. That avoided early dependence on external credentials, provider-specific failure handling, background jobs, retention questions, and security review. Staff could still capture relevant context, but the system did not pretend to be a full integration platform.

The third safeguard was keeping authorization ahead of search. NIST's ABAC model frames access decisions around subject, object, operation, and environment conditions. In this product, that translated into resolving viewer capabilities first, restricting searchable entity types, applying object visibility, and excluding unpublished lifecycle states.

From that work, I set a clear rule for future AI: generated answers must not use a broader data boundary than deterministic search. If an assistant retrieves records, it should use the viewer's permissions, return sources the viewer can access, and fail closed when records or permissions are unclear.

The NIST AI Risk Management Framework adds a broader governance lens around validity, reliability, accountability, transparency, and context of use. For this product, the practical implementation rule was simple: do not put generated answers ahead of governed records.

The direction I championed gave the team a safer path to AI without requiring a second governance model.

The product could identify authoritative objects, attach work and knowledge to stable identifiers, distinguish lifecycle states, enforce visibility, preserve record metadata, and search deterministically within permission boundaries. Those capabilities gave later AI retrieval and summarization a safer base.

The first-release scope also gave the organization useful value without AI. Staff could find governed material, follow lifecycle state, understand ownership, capture external references, and rely on permission-scoped search. The assistant could wait because the operating model handled the higher-risk work first.

"No AI first" applies to knowledge products where accuracy, confidentiality, auditability, and retention matter. That includes institutional operations, grant and project management, legal and policy workflows, healthcare administration, education operations, internal knowledge bases, and regulated records environments.

The pattern is not "never add AI." It is "make AI obey the system of record." Start with stable entities, lifecycle states, permission-scoped deterministic search, explicit retention rules, and audit metadata. Then add AI as a narrow layer that summarizes, drafts, or helps users discover governed material with citations.

Before adding AI to a knowledge product, write the record states, permission boundary, retention rule, and deterministic search contract that the assistant must obey. If those cannot be written clearly, the product is not ready for generated answers.

• SP 800-162, Guide to Attribute Based Access Control (ABAC)
• AI Risk Management Framework | NIST
• Using the Django authentication system
• Customizing authentication in Django
• Constraints reference
• How to create custom django-admin commands