Key takeaways
- Governance must be enforceable: Policies documented in PDFs are valuable, but governance is strongest when controls are built directly into the platform’s execution path.
- AI governance principles remain relevant: Human oversight, traceability, and sound data governance are useful design principles for internal AI systems, even when they are outside high-risk regulatory categories.
- Four controls matter most: Approval gates, append-only audit logs with actor attribution, permission-bound AI, and a documented (ideally empty) list of third-party AI processors provide a strong governance foundation.
- Local inference simplifies compliance: Running AI models entirely on your own infrastructure removes an entire class of external AI processors from security and privacy assessments.
- Architecture over configuration: Megapodes implements these controls as architectural invariants rather than optional settings, helping ensure they remain consistently enforced.
Why internal tools became a governance problem
For a decade, internal tools were the low-stakes corner of the software estate: admin panels, dashboards, request trackers. Then two things changed. First, AI moved into the tools themselves — assistants that draft records, summarize customers, classify tickets, and increasingly build and modify the applications. Second, regulators caught up. The EU AI Act entered into force in 2024 with obligations phasing in through 2026 and beyond, and it regulates AI systems by risk, not by whether the users are employees or customers.
The uncomfortable implication: an “internal” tool that uses AI to influence decisions about people — prioritizing leads, screening requests, summarizing employee data — is still an AI system your organization deploys. Even where a given tool lands in a minimal-risk category, the Act’s underlying expectations (human oversight, logging, transparency, data governance) have become the de facto template security and compliance reviewers apply to all AI tooling. Building to that template is now the path of least resistance, not gold-plating.
What enterprise AI governance actually requires
1. Human oversight that can actually intervene
The EU AI Act’s human-oversight concept (Article 14, for high-risk systems) is often summarized as “a human in the loop,” but the operative requirement is stronger: the human must be able to understand what the system is doing and intervene or interrupt it. An approve button attached to an opaque blob of AI-generated code does not meet that bar — nobody can meaningfully review what they cannot read. Effective oversight requires that AI output be inspectable, bounded, and reversible at the point of review.
2. Logging and traceability
When an auditor, regulator, or incident responder asks “what did the AI change, when, and on whose authority?”, the answer must come from records, not recollection. That means logs that are append-only (so they cannot be quietly edited), attributable (which actor — human or AI — performed each action), and complete (covering AI actions, not just human ones). Record-keeping and traceability run through the Act’s high-risk requirements, and they are precisely what SOC 2-style audits ask for anyway.
3. Data minimization
An AI assistant that can read the entire database to answer any question is a data-protection incident waiting for a prompt. Minimization means the AI’s access is scoped to its task and its role: a support-facing AI sees support data, within the same row- and field-level limits a human support agent would have. If the AI’s permissions are broader than any human role in the system, your governance model has a hole.
4. No shadow processors
Under GDPR — and analogous regimes such as India’s DPDP Act 2023 — every third party that touches personal data on your behalf is a processor requiring a documented legal basis, a contract, and inclusion in your records of processing. AI features quietly wired to cloud LLM APIs create shadow processors: data flows your DPO never enumerated because they were a product feature, not a procurement decision. Governance requires that the full set of AI data flows be known, intended, and contractually covered — or better, that the set be empty because inference never leaves your network.
The practical checklist
Translate the four requirements into questions you can put to any platform vendor — or to your own stack:
- Approval gates: Is there a mandatory human approval step before AI-proposed changes take effect? Can it be bypassed by configuration, API, or the AI itself? What does the reviewer actually see?
- Append-only audit with actor attribution: Are AI actions logged in a store that cannot be rewritten? Does each entry distinguish human actors from AI actors? Can you export it for your auditors?
- Permission-bound AI: Does the AI operate under the same authorization system as human users, enforced server-side? Or does it hold a privileged service account?
- No third-party inference: Where does each AI feature send data? Is there a cloud fallback that activates silently when the primary path fails? Can the platform run fully air-gapped?
A vendor who cannot answer these crisply is telling you the answers.
How Megapodes implements each item
Megapodes was designed with these controls as architectural invariants — properties of how the system is built, not policies layered on top. The platform is engineered for regulated environments: its controls are designed in alignment with ISO 27001 (information security management), GDPR and India’s DPDP Act 2023 (data protection), SOX ITGC (change management, access control, and audit trails), and SOC 2-style trust criteria. Certification programs are on the roadmap; architecture documentation and control mappings are available to customers under NDA. In detail:
Human oversight: the approval gate is the pipeline
The build-time AI agent (LangGraph orchestration over a local LLM via Ollama) never generates executable code. It emits schema-validated declarative metadata — collections, fields, relations, pages, workflows, ACL — which passes Zod schema validation, business-rule validation, and a migration dry-run before a human sees it. The reviewer is shown a changeset enumerating every mutation, with destructive items individually flagged and the data at risk named. Nothing applies until a human approves; on approval, changes apply transactionally. Because the AI’s output is bounded metadata interpreted by a fixed, tested runtime, review is genuinely possible — you are reading structure, not auditing generated code. See how the build pipeline works.
Traceability: append-only audit with actor types
Every gated mutation and every AI action lands in an append-only audit_log with an explicit actor type: human, ai_build, or ai_employee. When someone asks what the AI did last quarter, the answer is a query, not an investigation. This structure is designed in alignment with SOX ITGC change-management and audit-trail requirements and SOC 2-style trust criteria — it supplies the evidence those audits ask for, while certification of any deployment remains your organization’s program.
Minimization: AI under the same three-layer authorization
Runtime AI Employees are role-bound and restricted to data-only tools (read, summarize, extract, classify, fill_form, answer). They pass through the same three server-side enforcement layers as human users — role ACL, forced PostgreSQL Row-Level Security, and field-level masking applied in SQL — and are hard-denied the build surface server-side. The build-time and runtime AI planes cannot cross, a boundary tested adversarially. The full model is documented in the Trust Center.
No shadow processors: local inference, fail-closed
All inference — build-time agent and runtime AI Employees — runs against a local LLM via Ollama on your own GPU host, inside your network, air-gap capable. There is no cloud fallback: if the local model is unavailable, AI features fail closed rather than routing data elsewhere. For your records of processing, the list of third-party AI processors introduced by Megapodes is empty. That single property removes an entire section from most data-protection impact assessments and is the reason security reviews of Megapodes enterprise deployments tend to focus on your infrastructure, not ours.
Governance as a capability, not a tax
The pattern among teams handling this well is that governance done architecturally is faster, not slower. When the approval gate shows a complete, dry-run-verified changeset, approving takes minutes and the organization gains the confidence to let AI build more. When governance is a policy document and a hope, every AI initiative stalls in review. The approval gate is not friction on the product — it is the product. Explore the full feature set or compare deployment options on the pricing page.
Frequently asked questions
Why use three authorization layers instead of one well-tested one?
Because the layers fail differently. An application-layer ACL bug leaks whatever that code path touched; forced Row-Level Security in PostgreSQL still filters the rows; SQL-level masking still strips protected fields. Defense in depth means a single defect produces a degraded, still-safe result instead of a breach — and each layer is simple enough to reason about independently.
Does PostgreSQL Row-Level Security work with connection pooling?
Yes, if the session context is handled with discipline. Megapodes sets the user’s identity and roles as transaction-scoped session GUCs at the start of each transaction, so the context lives and dies with the transaction rather than the pooled connection. Policies treat a missing or empty GUC as deny, so a connection that skipped context-setting returns zero rows instead of another tenant’s data.
Why apply field masking in SQL rather than in application code?
Because data that never leaves PostgreSQL cannot be leaked by anything downstream. If masking happened in the application, the unmasked values would exist in database results, ORM objects, and memory — one forgotten code path away from a serialized response. Applying masking in the query itself means logs, error payloads, exports, and AI context windows only ever see the masked form.
Do AI Employees get any special data access?
No. An AI Employee acts under a role exactly as a human user does: its tool calls pass the same ACL checks, run under the same forced RLS policies via the same session GUCs, and receive the same field masking in SQL. It is additionally hard-denied the build surface server-side, and every action it takes is recorded in the append-only audit log with actor_type ai_employee.
Put the authorization stack in front of your security team
We will walk through ACL, forced RLS, and SQL-level masking against your own data model — and answer the hard questions live.
Self-hosted — your data never leaves your network · Every change human-approved and audit-logged · SSO/OIDC available · We support your security review
