think
16px
820px
← all files

Enterprise-Readiness Gaps — AHU AI Platform

Date: 2026-07-08
Scope: what's still missing for this to be a genuinely enterprise-grade production system, beyond the infrastructure hardening and migration architecture already covered in the two earlier audits. Builds on:
- Server delivery audit — the 6 hosts, hardening pass
- Production migration readiness audit — repo→host mapping, architecture decisions

TL;DR

The infra and migration work so far covers "can the platform run". Enterprise-grade also asks "can it be trusted with real people's legal identity data, held accountable when something goes wrong, and operated by more than one person without tribal knowledge". Four gaps stand out as genuinely new — not smaller versions of things already tracked:

  1. This system is squarely inside Indonesia's PDP Law (UU No. 27/2022), and one finding from the last audit — the chatbot's synthesis calls going to Alibaba Cloud (China) — isn't just an architecture violation, it's a cross-border personal-data-transfer compliance question with real penalties (up to 2% of annual revenue, criminal exposure up to 6 years for serious violations). This deserves a legal review, not just an infra fix.
  2. Access is currently shared credentials, not identity. Two Unix accounts (ai-developer, vigilia) shared across however many people touch these boxes is not compatible with "who did what" accountability once this is a production system of record for government legal-entity data.
  3. Observability was stood up but only partly connected. node_exporter and disk-alerting exist on all 6 hosts, but nothing scrapes them yet, and there's no centralized log search. The "nothing pages a human" half of this gap has since closed — Keep (keephq) was deployed 2026-07-09 as a self-hosted escalation layer and is already live for the Observatory's EWS warnings (see update below) — but auth on it is still NO_AUTH, and infra metrics (Prometheus) aren't wired into it yet.
  4. Nothing here has been through a security review or restore test. No vulnerability scanning, no pentest, and backups (still not provisioned at all — carried over as an open item) are only real once a restore has actually been tried.

Below, organized by domain, roughly in priority order within each.

1. Legal & regulatory compliance — new, and time-sensitive

This platform processes KTP (national ID), NPWP (tax ID), and notarial deed data for Indonesia's Ministry of Law business registry function. That's personal data, arguably at "large scale" and touching identity-document categories, processed by a government-linked system. Indonesia's Personal Data Protection Law (UU No. 27/2022, "PDP Law") applies, and its two-year transition period ended October 17, 2024 — meaning full legal exposure is already in effect, not a future date to prepare for.

Three concrete implications for this platform specifically:

  • Data Protection Officer (DPO). The law requires appointing one when processing is large-scale, involves systematic monitoring, or covers sensitive categories (which includes identity/biometric-adjacent data). This platform plausibly triggers that threshold. Worth confirming with legal counsel whether AHU/the ministry already has one for its broader mandate, or whether this platform needs its own.
  • Cross-border transfer, concretely. The PDP Law's cross-border rule is three-tiered: (a) the receiving country has an assessed "adequacy" of protection, (b) failing that, appropriate safeguards (binding corporate rules, standard contractual clauses) are in place, or (c) failing both, explicit data-subject consent. The chatbot's synthesis calls to Alibaba Cloud DashScope (China) send whatever the user asked — potentially including personal data — to a jurisdiction that has no confirmed adequacy assessment, almost certainly without safeguards or consent in place, and without the separate transfer-reporting obligation (designated country, recipient, date, purpose) that Indonesian regulation (MOCI Reg. 20/2016 Art. 22) requires around such transfers. This makes the "no external LLM calls in production" decision from the migration audit a compliance requirement, not just an architecture preference — worth flagging explicitly to whoever owns legal risk, since it changes the decision from "good practice" to "probably already exposed today, on staging."
  • Breach notification. 72 hours to notify both the regulator and affected individuals. That's a concrete number to build an incident-response runbook against (see §5) — "we'll figure it out when it happens" isn't compatible with a 72-hour clock. Update (2026-07-09): Keep (see §3/§6) now gives this an actual operational backbone — escalation policies, ack, on-call scheduling — instead of nothing. It's infrastructure for meeting the clock, not the clock itself: someone still has to define which Keep alerts represent a reportable breach and wire the actual regulator/data-subject notification steps as a documented workflow, ideally inside Keep rather than as tribal knowledge.

Penalties are real: administrative sanctions up to 2% of annual revenue, plus potential criminal liability (up to 6 years) for serious violations. Recommend this section goes in front of whoever handles legal/compliance for the ministry relationship, not just the engineering team — it's outside what infrastructure work alone can close.

(Enforcement today sits with Komdigi's Directorate General of Digital Space Supervision; the law's dedicated supervisory agency is still being stood up, but that doesn't reduce current exposure under the law as written.)

2. Identity & access management — currently below enterprise bar

Right now, admin/dev access to all 6 production hosts is two shared Unix accounts with password auth (ai-developer for AI-assisted sessions, vigilia shared across the whole dev team) — a deliberate choice for convenience, made explicitly earlier this session. Worth being clear-eyed about what that trades away as this becomes a real production system:

  • No per-person accountability. If something goes wrong on ahu-dmz-01 at 2am, "who ran that command" has one answer today: "someone with the shared password." For a system holding notarial/identity data, that's a real gap if it's ever audited or investigated.
  • No individual deprovisioning. When someone leaves the team, rotating a shared password is the only lever — every other person with that password has to get the new one too. Individual SSH keys per person (still allowing password fallback if that's the priority) solve this without giving up convenience.
  • No MFA. Password-only SSH, even scoped to the admin/VPN range, is a single factor protecting production infrastructure.

Recommend, roughly in order of effort-to-value: (a) individual SSH keys per developer even if password auth stays enabled as a fallback — this alone restores per-person audit trail without losing the convenience that motivated the shared-account decision; (b) if the dashboard/observatory UI ever gets real users beyond a handful of admins, real auth (SSO/SAML against whatever directory the ministry already uses, if any) rather than ad hoc accounts.

3. Observability — built the sensors, didn't wire them to anything

From the hardening pass: prometheus-node-exporter runs on all 6 hosts, and a disk-alert timer logs to syslog at 70%/85%. Neither is actually "monitoring" yet in the sense that matters for production:

  • Nothing scrapes the exporters yet. No Prometheus server is pointed at any of the 6 hosts. The metrics exist; nobody's reading them. (Planned: Prometheus + Grafana on ahu-gov-01, per the migration audit's §7-A infra prompt — not built yet.)
  • Paging is now a solved problem, not an open one. ~~The disk-alert timer writes to syslog, nothing pages a human~~ — update (2026-07-09): Keep (keephq) was deployed as a self-hosted escalation layer, already ingesting real warnings from the Observatory's EWS notifier (verified live: e.g. probing/jailbreak-attempt and abnormal-call-volume warnings, deduped/auto-resolved by fingerprint). What's still missing: infra-level alerts (disk/CPU/etc. from Prometheus, once it exists) aren't wired into Keep yet — the plan is Prometheus feeds Keep directly rather than a separate Alertmanager, so infra and EWS alerting consolidate onto one escalation brain (see migration audit §A.1). Keep itself still runs AUTH_TYPE=NO_AUTH — see §2's IAM gap, same category of issue, now on an incident-response tool specifically.
  • No centralized logs. Right now, debugging anything means SSHing into the specific host and reading that container's docker logs. At 6 hosts and growing, a log aggregator (Loki is the natural fit — lightweight, pairs with Prometheus/Grafana, matches the platform's already-adopted Prometheus-format /metrics convention) pays for itself the first time something breaks and nobody knows which host to look at first.
  • No dashboards for infra-level health, distinct from the AI-audit Observatory dashboard (which is a different thing — that's business/compliance audit, not "is the disk full" or "is the gateway's p99 latency spiking").

Recommend: stand up Prometheus + Grafana on ahu-gov-01 (already scoped in the migration audit's §7-A/A.1), feeding Keep directly for alerting rather than a separate Alertmanager. Loki is the natural next addition for centralized logs once that's up, whenever the team wants it.

4. Security — beyond the network layer already covered

The firewall/segmentation work covers network-level isolation. Enterprise-grade security has layers above that which haven't been touched:

  • Internal traffic is plaintext HTTP. OCR's calls to PaddleOCR/cleanup-LLM, and most inter-service calls surveyed in the migration audit, use http://, not https://. Once these cross real network segments (rather than a single Docker host's loopback), that's cleartext PII on the wire, even if it's "just" internal. Worth mutual TLS or at minimum TLS termination between zones for anything carrying document/identity data.
  • No vulnerability scanning. No container image scanning (Trivy/Grype are the standard, low-effort options), no dependency scanning (npm audit/pip-audit/govulncheck in CI), no OS package vulnerability tracking beyond the monthly patch window already set up.
  • No rate limiting or abuse protection on the public surface. The LB/WAF gap is already tracked as open infrastructure; worth calling out its security angle specifically — a WAF alone doesn't stop a scripted abuse pattern hitting the chatbot's search/orchestrate endpoints at volume. Rate limiting per IP/session belongs at the edge, whatever that ends up being.
  • No security review or penetration test before go-live. Given the data sensitivity and the PDP Law exposure above, an external or internal security review before production traffic is the kind of thing that's much cheaper to do proactively than after an incident forces it.
  • No documented incident-response process. Ties directly to the 72-hour breach notification clock in §1 — there should be a runbook for "we think something leaked" that doesn't start from zero at 2am. Keep (§3/§6) is now the mechanical layer this would run on (escalation policies, ack, on-call), but the actual process — what counts as a reportable incident, who decides, what the notification steps are — still needs to be written and configured as a workflow, not assumed to exist because the tool does.

5. Reliability & data protection

  • Backups: still not provisioned at all (carried over from the original delivery audit — the governance-DB backup target). Worth restating at enterprise scale: an unprovisioned backup target isn't "backups are risky," it's "there are no backups." For a system of record, this is arguably the single highest-priority open item across all three audits.
  • Backups, once they exist, need a restore test. An untested backup is a hypothesis, not a guarantee. Recommend a documented, periodic "restore this backup to a scratch instance and verify" drill, not just "the backup job ran successfully."
  • No RPO/RTO targets defined. "How much data can we afford to lose, how long can we afford to be down" hasn't been decided anywhere, which means there's no way to know if whatever backup cadence gets chosen is actually adequate.
  • Single-instance MVP tier, no HA yet — already flagged in the migration audit as a known, accepted tradeoff for now; repeating here only to note it's the same underlying "no redundancy" gap showing up in the reliability lens too.

6. Operational maturity

  • No runbooks beyond what's embedded in repo CLAUDE.md/OPS-NOTES.md files. Those are good and worth keeping, but they're scattered across repos and written for whoever's doing the work in the moment, not structured as "here's what to do when X breaks at 2am."
  • On-call/escalation now has a real tool (Keep, deployed 2026-07-09), but no configured process yet. Adopting Keep rather than building this into the Observatory was the right call — on-call/escalation is a large, commodity problem, not something worth re-implementing (see the migration audit §A.1 for the full reasoning). What's still missing is the human side: on-call schedules, escalation policies, and "who does what first" aren't configured in Keep yet — the tool existing isn't the same as the process existing. Also still open: Keep's own hardening backlog (auth, Postgres over SQLite, pinned image tags — §A.1 in the migration audit) before leaning on it for anything that actually matters.
  • No change-management trail beyond git history. Fine for a small team today; worth revisiting if/when more people start deploying independently — a lightweight "who approved this production change" record becomes valuable exactly when it feels unnecessary to set up.

7. Vendor & licensing

  • Azure Document Intelligence, on-prem container — confirm the licensing terms actually cover production/commercial use at whatever volume this platform expects, not just PoC/evaluation licensing. Easy to overlook since it's already "on-prem" and feels self-hosted, but it's still a licensed Microsoft product with its own terms.
  • Vendor concentration risk — worth a short note (not a blocker) that PaddleOCR, Azure DI, and the vLLM stack all depend on specific vendor/open-source project continuity; not urgent, but worth knowing as a dependency map exists somewhere.

Priority order, if picking where to start

  1. Backup target (§5) — already the most-repeated open item across three audits; there is currently no recovery story at all.
  2. PDP Law / cross-border transfer review (§1) — time-sensitive (already past the compliance deadline), and the DashScope removal already decided elsewhere gives legal a concrete, mostly-already-fixed starting point rather than a from-scratch problem.
  3. ~~Wire monitoring to an actual alert channel~~ — partly done (2026-07-09): Keep closes the "nothing pages a human" half (§3/§6). Remaining: enable auth on Keep (currently NO_AUTH), wire Prometheus infra metrics into it once that stack exists, and configure the actual on-call/escalation policies — the tool being deployed isn't the same as the process being defined.
  4. Individual SSH keys per developer (§2) — restores accountability without giving up the convenience the shared-account decision was made for.
  5. Everything else in §4/§6/§7 — real, but lower urgency than the four above.