Booster Analytics

We are no longer dealing with narrow AI use cases that optimize conversion rates or automate customer service responses. The era of general AI is here, where models can understand context, reason across multiple domains, and make decisions with minimal supervision. This model massively changes the game. And as CTOs, our data strategies must evolve — or we risk building AI on a crumbling foundation. Unfortunately, I have seen many CTOs bumbling around without being aware of the oncoming train. Perhaps their C stands for Connection Technology Officer.

---

Let’s not pretend this is a “just upgrade your model” kind of shift. No, this is an overhaul of architecture, governance, and capabilities. Below is my playbook for adjusting data strategy to thrive — not just survive — in the era of general AI.

1. From Pipeline to Platform Thinking

Old World: You built pipelines to serve narrow use cases — marketing analytics, fraud detection, or churn prediction.

New World: You need a flexible, general-purpose data and knowledge platform that supports agentic AI, retrieval-augmented generation (RAG), graph-based reasoning, and federated models.

Adjustment:

• Build or refactor toward modular, reusable components.
• Enable low-latency, schema-flexible data access through APIs and vector databases.
• Move from batch-first to event-driven and real-time streaming where context matters.

2. Embrace Knowledge Graphs + Semantic Layers

General AI isn’t just about having more data. It’s about connecting data in meaningful ways, in profitable ways. Static tables no longer suffice. You need to teach your AI what your organization knows.

Adjustment:

• Invest in enterprise knowledge graphs to link structured, semi-structured, and unstructured data.
• Create ontologies that accurately reflect your domain, including products, customers, processes, and other relevant entities.
• Make semantic metadata a first-class citizen in your data strategy.

This adjustment is not just a data engineering task — it’s an organizational knowledge modeling initiative. You will need cross-functional support.

3. Privacy and PDPA Become Execution Constraints, Not Checklists

General AI systems can hallucinate sensitive info, infer personal details, or leak data in generated output. In this era, data privacy isn’t just a legal checkbox — it becomes an execution boundary.

Adjustment:

• Implement PDPA-aware internal guardrails (especially in Southeast Asia).
• Classify data at ingestion and define usage policies at the API level.
• Use synthetic data, masking, and differential privacy not as afterthoughts, but defaults.

You will also need “data whisperers” who understand law, risk, and tech. That’s your new hybrid role to hire.

4. Contextual Memory and Long-Term State

LLMs can simulate reasoning, but they tend to forget quickly. What your agents need is context memory, anchored in your enterprise data and history.

Adjustment:

• Add persistent memory stores (e.g., vector DBs with time-stamped embeddings).
• Architect LLM applications to maintain a long-term state across sessions and agents.
• Index interaction logs and decision history for RAG-based recall.

This adjustment involves integrating conversation history, previous task outcomes, and knowledge updates into your data architecture.

5. Data Quality Moves from Pipelines to Feedback Loops

The truth is, your first data pass is never perfect. With general AI, the cost of low-quality data is multiplied because AI will amplify it in its outputs.

Adjustment:

• Implement continuous feedback loops: human-in-the-loop validation, reinforcement learning from human feedback (RLHF), and automated anomaly detection.
• Tag datasets with provenance and trust scores — then let agents prioritize higher-trust sources.
• Align data quality metrics with business outcome metrics. Fixing “missing data” is not as important as fixing “misleading outputs.”

6. Data Governance Meets Prompt Engineering

Prompts are the new SQL. In the general AI era, what you ask the AI matters as much as what data it has access to.

Adjustment:

• Govern prompt templates the same way you govern dashboards and SQL queries.
• Set up internal prompt repositories with versioning, tagging, and approvals.
• Train business users to write prompts responsibly using internal guardrails.

Prompt engineering becomes a domain of its own. Please treat it with the same seriousness you once gave to BI self-service.

7. Agentic Collaboration Demands Role-Aware Data Permissions

Your general AI agents will act on behalf of users and systems. They need to know who they are, what they’re allowed to see, and how to behave.

Adjustment:

• Adopt fine-grained, role-based access control — not just at the database layer, but also at the agent and application layers.
• Embed identity and authorization context into every data request and response.
• Use policy-as-code (e.g., OPA, Rego) to manage data entitlements at scale.

You’re not just designing systems for humans to use anymore — you’re designing for machines that work like humans.

8. From Centralized Teams to Federated Data Agents

A single data team can’t keep up with the general AI demand across the organization. You need data agents that support local autonomy while enforcing global standards.

Adjustment:

• Build domain-specific data products owned by business units.
• Enable team-level RAG deployments that feed into a central vector fabric.
• Use metadata registries and lineage tracking to ensure discoverability and governance.

Your data strategy becomes a federation — aligned, but not centralized.

Final Thought: CTOs Must Become Data Strategists, Not Just Tech Leaders

The general AI era will expose your weakest data links — and exploit them at scale. A CTO who still sees data strategy as a “back-end concern” will find themselves locked out of AI transformation.

Instead, embrace this moment as a strategic inflection point. Data strategy is your AI strategy. Adjusting it now is the difference between building agents that learn and ones that hallucinate.

If you’re a CTO staring down this shift, start with one question: What parts of my data stack assume that people — not machines — are the primary users?

That’s where your transformation begins.