Technical next-step brief

Operationalizing an AI utility partner.

Not a contract page. This is the working model for support, deployment, security, compliance, local vendor coordination, and the technical questions we need answered before a real pilot.

StatusDemo complete
Next milestoneTechnical discovery
Pilot postureRead-only first
01
Partnership shape

We provide the AI technology layer. Local teams keep the grid grounded.

A

AI enablement partner

We maintain the agent platform, model upgrades, evaluation process, prompt quality, safety controls, and roadmap as AI capabilities improve.

B

Local vendor coordination

Domestic telecom, field, language, and systems partners stay involved so implementation supports Tanzania capability rather than replacing it.

C

Phased deployment

Start with customer-service intelligence and read-only system access. Move toward controlled write actions only after security, audit, and approval gates are proven.

D

Long-term strategy

The roadmap expands from calls and updates into outage learning, field support, planning insight, and future grid modernization support.

02
Deployment ladder

Move from demo to production without jumping into risky control paths.

0 Current

Demo

Fake data, live voice demo, website, and console.

1Next

Technical discovery

System map, data inventory, risk review, pilot lane selection.

2

Read-only pilot

Secure access to approved datasets: outage status, account lookup, FAQs, payment references, work-order status.

3

Assisted operations

Agent drafts tickets, summaries, outbound updates, and dispatch recommendations for human approval.

4

Controlled automation

Low-risk actions execute through approved APIs with logs, permissions, rollback, and human override.

03
Technology path

A utility-hosted MCP-style gateway is the cleanest next architecture.

The agent should not connect directly to SCADA or unmanaged production databases. A controlled gateway gives approved tools, audit logs, rate limits, and a clean separation between AI reasoning and utility systems.

Channels
Voice, SMS, WhatsApp, web, operator console
Agent layer
Swahili/English triage, identity flow, summaries, escalation, evaluations
MCP gateway
Approved tools for account lookup, outage status, payment reference, ticket draft, notification draft
Utility systems
CRM, billing, OMS, dispatch/work orders, document knowledge base, reporting warehouse
OT boundary
No direct grid-control actions in the pilot. OT remains segmented and governed by utility safety rules.
04
Controls before connection

Security and compliance work starts before integration, not after.

i

Data protection

Define controller/processor roles, data minimization, retention, consent/notice language, data residency expectations, breach process, and PDPC registration posture.

ii

Access and audit

Use named accounts, MFA, least privilege, approval gates, tamper-resistant logs, environment separation, and a no-secrets-in-demo rule.

iii

AI safety

Evaluate hallucination, prompt injection, unsafe recommendations, biased language handling, over-reliance, escalation quality, and outage misclassification.

iv

OT separation

Keep the first pilot on IT/customer operations. Any future OT-aware work needs segmentation, safety review, read-only telemetry first, and human override.

v

Operational resilience

Plan uptime monitoring, fallback call routing, model/provider failover, manual handoff, incident response, and disaster-mode scripts.

vi

Export and vendor review

Confirm cloud providers, model vendors, encryption, telecom routes, and U.S./Tanzania restrictions before sending sensitive utility data across borders.

05
Ongoing support

The operating model is continuous improvement, not one-time software delivery.

Run support

Health monitoring, call-quality review, incident response, model/provider fallback, prompt updates, channel troubleshooting, and weekly performance review during pilot.

Improve support

Monthly roadmap review, new AI capability assessment, user feedback digestion, local language tuning, integration backlog, and executive reporting.

06
Questions for the meeting

What we need to ask to move the technology forward.

Systems

  • Which systems hold account, meter, outage, payment, and work-order data?
  • Which systems already expose APIs, reports, files, or secure database views?
  • Who owns each system and who can approve pilot access?

Pilot lane

  • Which first lane matters most: outage calls, payment/token support, planned maintenance, or dispatch triage?
  • Which region, call volume, and languages should the pilot cover?
  • What counts as success after 30, 60, and 90 days?

Security

  • What network path is acceptable: VPN, private link, utility-hosted gateway, or file exchange?
  • What data cannot leave Tanzania or cannot leave TANESCO-controlled infrastructure?
  • What logs, approvals, and incident notifications are mandatory?

Operations

  • Who receives escalations when the AI should not answer?
  • Which local vendors should be part of telecom, support, field, or language operations?
  • Who signs off on scripts, customer-facing wording, and restoration-message templates?
Research basis

Grounded in TANESCO customer-service surfaces, EWURA regulatory scope, Tanzania PDPC data-protection notices, NIST AI/OT risk guidance, CISA critical-infrastructure cybersecurity goals, and current U.S. BIS export-control posture.

Return to live demo