Can You Trust AI Enough to Act on It? Q&A with Biplab Banerjee

The challenge in enterprise AI is not whether models are accurate, it is whether organizations can trust AI-driven outcomes enough to take action at scale.The discussion would focus on a key gap in real-world AI deployments, not model capability, but how AI outputs are operationalized. In many systems, AI-generated recommendations are directly executed, raising challenges around accountability, auditability, and consistent decision-making at scale.

Q1. In your experience working with telecom operators at scale, what is the most common misconception organizations have about what it actually means to “trust” an AI system — and how does that misconception lead them into trouble when they try to operationalize AI-driven decisions?

Answer :  The most common misconception is that “Trust” is “Model Accuracy”. Organizations believe that if a model achieves high precision or confidence in testing, it can produce expected outcomes in production.  In Enterprise telco environments, trust is not really about whether the model is usually correct. Trust is about whether the organization can consistently understand, govern, reproduce, and control decisions under real operational conditions

This distinction becomes critical the moment AI moves from analytics into operational workflows.   

We find telcos struggling to determine the answer to : 

“Can we explain exactly why this action happened, under what context, using which data, and whether the system behaved consistently across millions of events?”

A lot of times, we find AI operationalization by embedding model outputs directly into fragmented application stacks; CRM systems, policy engines, mediation systems, network orchestration platforms, Kafka consumers, microservices, etc., without a centralized deterministic decisioning layer.

This can result in inconsistent actions across channels, race conditions between systems, inability to replay or audit decisions, policy drift, non-deterministic customer experiences, and, ultimately, operational teams losing confidence in the system itself.

At the scale in which telcos operate, trust is less about “intelligence” and more about whether the architecture can guarantee criteria such as deterministic execution, contextual consistency, governance, and bounded behavior under failure conditions. Without these, even highly accurate AI models become liabilities.

Q2. There is an important but often blurred distinction between an AI recommendation and a system decision. In practice, where does that line get crossed, and what are the real-world consequences — in terms of accountability, auditability, and risk — when organizations fail to keep those two things architecturally separate?

Answer : An AI recommendation is probabilistic insight.

A system decision is a deterministic operational commitment.

That line gets crossed when systems trigger actions directly based on AI outputs without passing through a deterministic, policy-aware decision layer.

For example: “A particular subscriber has a high probability of fraud” is a recommendation. “Suspending that particular subscriber immediately” is a system decision.

In many enterprise environments, especially those modernizing quickly, these become tightly coupled through event-driven workflows and automation pipelines. The model output effectively becomes the action itself, creating serious operational risks.

First, accountability can be difficult to establish. With outcomes such as denied access, service degradation, roaming block, or a failed transaction, organizations often cannot clearly reconstruct what happened. Which data influenced the outcome? What policies were active? Which version of the model was used? Did another system have a conflicting state at the same moment?

Second, auditability breaks down. Most traditional architectures scatter decision logic across APIs, microservices, orchestration engines, message brokers, rules engines, and operational systems.

The AI score may be logged somewhere, and the resulting action elsewhere, but the full causal chain is difficult to reconstruct in real time.

Third, risk amplification becomes a major issue at scale. Telecom systems operate at enormous event volumes and extremely low latency requirements. Even small inaccuracies or timing inconsistencies can cascade rapidly into false fraud actions, customer experience degradation, regulatory exposure, or large-scale operational instability.

The organizations that succeed operationally are those that can unify real-time inference, continuously changing operational context, policy and risk evaluation, transactional validation, and action execution.  Because in production environments, the real challenge is not generating an AI recommendation. The challenge is ensuring that every recommendation is evaluated against live business state, governed consistently, executed transactionally, and replayed explainably, all within milliseconds and at massive concurrency.

Q3. You work with high-scale, low-latency distributed data systems in an industry where milliseconds matter. What does “consistent, auditable decision-making at scale” actually require at the infrastructure level — and where do most enterprise architectures fall short when AI outputs need to be acted upon in real time?

Answer : Consistent, auditable decision-making at scale requires the ability to process data, evaluate context, execute decisions, and persist outcomes within a unified real-time operational flow.

Conceptually, that sounds straightforward. Architecturally, it is extremely difficult.

In high-concurrency operational environments such as telecom, financial services, payments, airlines, logistics, retail, cybersecurity, and manufacturing, decisions are highly state-dependent.

They rely on continuously changing context, such as customer or subscriber activity, transaction history, fraud indicators, inventory or capacity availability, network or device conditions, location and session state, entitlement and policy controls, operational risk signals, and prior actions already taken by other systems.

The challenge is that this context changes continuously, concurrently, and at very high event volumes. Most enterprise architectures today are fragmented across: streaming platforms, external caches, asynchronous workflows, analytical systems, orchestration layers, AI inference services, and eventually consistent data stores.

Even if individually, many of these components scale well. Collectively, however, they often struggle to maintain deterministic behavior in real-time concurrency, where AI outputs must drive operational actions within milliseconds.  Moreover, leading to problems such as conflicting actions from different systems, stale or partial decision context, duplicated or out-of-order execution, inconsistent customer outcomes, and difficulty reconstructing the exact causal chain behind a decision.

For AI-driven operational systems, the infrastructure layer must provide: real-time state awareness, low-latency stream processing, transactional consistency, deterministic execution, concurrency control, horizontal scalability, and built-in auditability.

Importantly, these capabilities cannot simply be assembled loosely across disconnected layers without introducing coordination complexity, timing gaps, and operational risk.

The industry is increasingly realizing that operational AI requires something much closer to a real-time transactional decisioning platform than a traditional architecture.  Once AI outputs begin driving actions in milliseconds, the challenge is no longer generating intelligence.

The challenge becomes operationalizing that intelligence safely, consistently, transactionally, and explainably at scale.

Q4. Tightly coupling AI outputs to automated actions is one of the riskier patterns emerging in enterprise deployments. Can you walk us through a concrete scenario — ideally from the telecom world — where this coupling created problems, and what a better-architected approach would have looked like?

Answer: A strong real-world example comes from one of the largest telecom operators in Indonesia, which implemented a large-scale real-time customer engagement and loyalty platform powered by AI-driven “next best action” decisioning for 60 million subscribers.

The system continuously analyzed: recharge behaviour, usage patterns, inactivity, churn signals, and responsiveness to offers, to trigger highly personalised campaigns in real time.

The existing incumbent solution was to tightly couple AI outputs directly to campaign execution. If the model detected churn risk or recharge probability, offers were immediately pushed to the customer.

At national scale, this created operational issues very quickly.  Customers could simultaneously qualify for: retention campaigns, loyalty rewards, recharge incentives, and upsell offers across multiple channels because different systems were reacting independently to rapidly changing customer behaviour.

We worked with one of our partners and figured out that the AI models themselves were not necessarily wrong. The real issue was architectural!  There was no unified real-time decisioning layer maintaining a single authoritative customer state and coordinating actions transactionally.

This led to duplicated offers, inconsistent customer experiences, excessive incentive leakage, and inaccurate campaign attribution.

The more mature approach evolved toward a real-time stateful decisioning architecture where AI generates recommendation signals, but final actions are validated against live customer context, eligibility rules, policy controls, prior actions, and transactional state consistency before execution.

At this scale (billions of daily events and millions of subscribers), the challenge was not generating intelligence. The challenge was executing that intelligence consistently, deterministically, and safely in real time.

Q5. Looking at where enterprise AI deployments are heading over the next three to five years, what is the role of a real-time, deterministic decisioning layer — and why do you believe that trust in AI systems is ultimately an architectural problem rather than a model accuracy problem?

Answer: Over the next few years, as AI becomes deeply embedded into operational systems, the real strategic layer will not just be the model, or the Agentic capabilities, it will be the real-time decisioning infrastructure sitting between AI inference and business action.

AI models and autonomous agents will continue to evolve rapidly, and operationalizing AI safely at scale, in real time, with consistency, accountability, and governance, will become more challenging as a result.

The reason trust is fundamentally an architectural problem is simple: AI is probabilistic, but enterprises operate on commitments.

A model can predict intent, risk, or next best action but it cannot guarantee: the current live state of the system, transactional consistency across distributed environments, policy enforcement, or that an inference generated a few seconds earlier is still valid at execution time. Those guarantees can only come from the infrastructure layer.

That is why enterprises are moving toward architectures where a deterministic, policy-aware, real-time decisioning layer sits in between that is continuously validating AI recommendations with live context, business rules, risk controls, and transactional state before actual execution.

That layer becomes responsible for: real-time contextual awareness, deterministic execution, auditability, transactional integrity, and operational resilience at scale.

Ultimately, trust in enterprise AI is not a model property. It is a system property and it has to be architected and engineered into the platform itself.

………………….………………………….

Biplab Banerjee, Real Time Data Architect, Volt Active Data.

With over 10 years of experience working with high scale System specially in the telecom industry, Biplab is a PreSales & Customer Success Consultant at Volt Active Data, a company that helps customers design and implement scalable and low-latency distributed data systems. He has a strong background in digital BSS, cloud infrastructure, automation, and AI solutions, IIOT, Distributed Databases, Distributed systems and holds Prince2® and ITIL® certifications. He has worked with 15+ telecom operators across different regions, delivering high-quality solutions and services, and building strong customer relationships. He has also received multiple awards for his exceptional contributions and performance, and has been an advisor to the leadership team. He is passionate about using his skills and knowledge to modernize and optimize data systems and processes, and to create value for his clients and company. 

His current interest is in data streaming and stream processing solutions, and he is open to collaborate and discuss on this area.

Sponsored by Volt Active Data.