The biggest threat to artificial intelligence may not be an inadequate model, it may be the unreliable data quietly shaping every decision the model makes. As organizations increasingly use AI for predictions, recommendations, and operational decisions, the quality and traceability of their data have become critical business concerns. Paras Pandey, a data engineer at Amazon with six years of experience in data engineering, cloud platforms, ETL development, automation, and applied machine learning, believes that trustworthy AI must be supported by accurate, secure, well-governed, and explainable data. His observations reflect an independent industry perspective and do not represent the systems, practices, or views of his employer.

The rapid development of generative AI, predictive analytics, and intelligent automation has encouraged companies to focus heavily on model capabilities. Businesses frequently compare models based on accuracy, speed, reasoning ability, and the number of tasks they can perform.

However, the reliability of an AI system is also determined by what happens before information ever reaches the model.

Incomplete records, inconsistent labels, outdated information, duplicated entries, and unrepresentative datasets can significantly affect AI performance. Even a technically advanced model may generate misleading conclusions when it is trained or operated using unreliable data.

This is why trustworthy AI is not solely a model-development challenge. It is equally a data-engineering, governance, and organizational responsibility.

The Reliability of AI Begins Before Training

An AI model learns patterns from the information provided to it. When the underlying data contains systematic errors or fails to represent the environment in which the model will operate, those weaknesses can influence the model’s recommendations and predictions.

In a traditional reporting environment, a data-quality issue may result in an inaccurate dashboard or an incorrect monthly report. In an AI-supported process, the same issue may affect a customer recommendation, risk assessment, operational alert, or automated decision.

The potential consequences become greater when AI outputs are used without sufficient human review.

Organizations should therefore evaluate the complete data supply chain supporting an AI system. This means understanding where information originates, how it is collected, which transformations are applied, how frequently it is updated, and which teams are responsible for maintaining it.

It also requires documenting the limitations of the dataset.

For example, a customer-behavior model may appear accurate overall while performing poorly for a particular region, product category, or demographic group that was underrepresented in the training data. Without proper analysis, that limitation may remain hidden until the model is already being used.

Reliable AI development begins by asking whether the available data is genuinely suitable for the intended decision.

Data Quality Must Be Built Into the Platform

Many organizations treat data quality as a cleanup exercise performed after a problem appears. Pandey believes a more dependable approach is to embed quality checks directly into the data platform.

Automated validation can help identify missing records, duplicate transactions, unexpected schema changes, unusual volume fluctuations, invalid values, and delayed information.

These checks should not be limited to whether a pipeline completed successfully.

A data pipeline may run without a technical error while still delivering misleading information. For instance, two departments may use different definitions for terms such as “active customer,” “completed transaction,” or “recognized revenue.”

Both datasets may appear technically valid, but they can produce conflicting conclusions.

Trustworthy data therefore requires a combination of technical controls and agreed business definitions. Important terms should be documented, consistently applied, and assigned to accountable owners.

Data-quality rules should also be aligned with the intended use of the information. A minor delay may be acceptable for a monthly performance report but unacceptable for a system evaluating time-sensitive financial activity.

The required standard depends on the decision the data will support.

Data Lineage Creates Traceability

Modern AI systems rarely depend on a single source of information.

They may combine data from operational databases, application logs, documents, customer platforms, sensors, external providers, and historical archives. Before reaching a model, the information may be cleaned, filtered, joined, aggregated, anonymized, or enriched through multiple pipelines.

Data lineage records this journey.

It allows teams to understand where a piece of information originated, which transformations were applied, when it was processed, and which models or applications consumed it.

When an AI system produces an unexpected result, lineage can help investigators determine whether the problem originated in the source data, transformation logic, pipeline configuration, or model itself.

Without this visibility, an organization may know that an output is unreliable without being able to explain why.

Strong lineage also supports reproducibility. If a model needs to be reviewed months after it was developed, teams should be able to reconstruct the dataset and processing logic used during training.

This becomes particularly important in regulated or high-impact environments where organizations may need to explain how a decision was reached.

Trust Requires More Than Model Accuracy

A model can perform well during testing and still be unsuitable for real-world use.

Trust also depends on reliability, fairness, transparency, security, privacy, and consistency. An accurate model that cannot be monitored, explained, or protected from misuse may still create significant risk.

Data conditions can also change after deployment.

Customer preferences evolve. Product offerings change. Economic conditions shift. New regulations are introduced. A model trained on historical patterns may gradually become less effective as the operating environment changes.

Organizations should therefore monitor both model performance and the characteristics of incoming data.

When substantial changes are identified, the appropriate response may involve retraining the model, updating a business rule, correcting a pipeline, collecting more representative information, or temporarily limiting automation.

Monitoring should not focus only on overall averages. Performance may need to be evaluated across relevant regions, products, customer groups, and operating conditions.

A model that performs well in aggregate may still produce unacceptable outcomes in a particular context.

Data Engineers Are Becoming Central to AI Governance

The role of the data engineer is expanding as artificial intelligence becomes more deeply integrated into enterprise operations.

Data engineers have traditionally focused on collecting, transforming, storing, and delivering information reliably. They are now increasingly responsible for establishing the controls that allow AI systems to operate responsibly.

Their work may include implementing automated quality checks, managing metadata, maintaining lineage, protecting sensitive information, enforcing access controls, and creating reproducible datasets for model development.

They may also be responsible for monitoring freshness, pipeline failures, unexpected changes, and downstream dependencies.

These responsibilities directly influence whether an AI model can be investigated, audited, reproduced, and trusted.

Pandey sees data engineering as part of the broader AI governance architecture rather than a supporting activity performed only behind the scenes.

When an organization develops an AI governance policy without strengthening its underlying data infrastructure, it risks creating rules that cannot be consistently enforced.

Governance must be reflected in the design of the platform itself.

Human Oversight Remains Essential

Reliable data can improve AI performance, but it does not eliminate the need for human judgment.

Some decisions are too complex, ambiguous, or consequential to be delegated entirely to an automated system. Organizations need to define where AI can act independently and where human review is required.

The appropriate level of oversight depends on the potential impact of an incorrect decision.

A low-risk recommendation may be suitable for automation. A decision involving employment, healthcare, financial eligibility, safety, or legal rights may require stronger review and accountability.

Human oversight should not be treated as a vague requirement. Organizations should establish who reviews an AI-supported decision, what information is available to that reviewer, and how an output can be challenged or overridden.

Trust is strengthened when people understand both the capabilities and limitations of the system.

Trustworthy AI Is a Shared Responsibility

Technology alone cannot create trustworthy AI.

Business teams must help define the meaning and acceptable use of important information. Data engineers must make technical limitations visible. Data scientists must document how datasets are selected and prepared. Security and governance teams must establish controls proportionate to the risks involved.

Leadership must also recognize that data quality is not a one-time improvement project.

Datasets, pipelines, and business requirements change continuously. Trustworthy data requires ongoing ownership, monitoring, and investment.

An organization should be able to explain what information was used, why it was appropriate, how it was transformed, which limitations were identified, and what safeguards were applied.

The future of artificial intelligence will not be shaped solely by organizations that build the most advanced models. It will also be shaped by those that create the most dependable foundations around them.

Before enterprises can reasonably ask customers, employees, regulators, and other stakeholders to trust their AI systems, they must first demonstrate that they can trust the data supporting those systems.

As organizations increase their reliance on business intelligence, analytics, and artificial intelligence, many are facing a familiar problem: demand for data-driven insights is growing faster than central data teams can deliver.

According to insights shared by Kamal Yadav, Principal Data and Insight Analyst at Brambles, the challenge is not only about limited resources. It is also about how data work is structured, prioritized, governed, and delivered across the organization.

Business teams now expect faster dashboards, automated reporting, predictive insights, and AI-enabled decision support. At the same time, central data teams remain responsible for maintaining trusted reports, protecting sensitive information, managing governance, ensuring consistent definitions, and supporting existing business-critical data services.

This creates a delivery bottleneck. Too many requests enter one central queue, while limited teams are expected to respond quickly without compromising quality or control.

When lead times become too long, business users often find their own alternatives. They may return to Excel, create local dashboards, or build manual reporting workarounds. These short-term fixes may appear practical, but they can create long-term problems. Different teams may begin using different numbers, definitions, and assumptions. Over time, reporting becomes duplicated, data quality becomes harder to manage, and trust in analytics starts to weaken.

The solution is not simply to hire more people. Additional resources may help, but they do not fix the deeper operating model issue. Organizations need a clearer way to manage demand, prioritize work, distribute ownership, enable self-service, and apply governance in a way that supports delivery rather than slowing it down.

Separating Run Work From Build Work

One of the first steps is to separate “run the business” work from “build the business” work.

Run work includes core dashboards, regulatory reporting, recurring performance reports, financial reporting, operational scorecards, and other business-critical data services. These activities require stability, service levels, ownership, and ongoing support.

Build work is different. It includes new dashboards, analytics products, AI use cases, predictive models, platform upgrades, and innovation projects. These initiatives are usually focused on future capability, transformation, or value creation.

When both types of work are placed in the same queue, delivery teams are constantly pulled in different directions. Urgent reporting issues interrupt strategic projects, while new initiatives can delay essential operational support. Over time, both run and build work suffer.

A stronger approach is to create separate delivery tracks with different prioritization rules. Run work should protect business continuity. Build work should be prioritized based on business value, urgency, complexity, and strategic importance.

This gives data teams a clearer view of capacity and helps business stakeholders understand the trade-offs involved.

Creating a Stronger Intake Function

Many BI and AI backlogs grow because requests enter delivery before they are properly understood.

A business user may ask for “a simple dashboard” or “one additional chart,” but the real work may involve missing source data, unclear metric definitions, complex integration, security constraints, or governance questions.

A dedicated intake function can reduce this problem significantly.

The intake team should act as the front door for data requests. Its role is to clarify the business need, understand the decision the request supports, assess value, identify complexity, estimate effort, and route the work to the right delivery path.

This function should include data business analysts who understand both business context and data complexity. These roles are different from traditional business analysts. They need to understand data sources, reporting logic, ownership, definitions, quality issues, and governance requirements.

Good intake prevents poorly defined requests from overwhelming delivery teams. It also helps identify whether a request should become a strategic data product, an enhancement to an existing report, a self-service use case, a quick analysis, or a lower-priority backlog item.

Using Product-Centric Delivery Pods

Another common cause of delay is fragmented delivery ownership.

In many organizations, data engineering, reporting, testing, governance, and business engagement sit in separate teams. Work moves from one group to another, creating handoffs, delays, and unclear accountability.

Product-centric delivery pods can help solve this problem.

A pod brings together the skills needed to deliver an outcome from end to end. Depending on the use case, this may include data engineers, BI developers, analysts, testers, governance specialists, and a product owner.

The product owner is responsible for the full lifecycle of the work. This includes understanding the business need, prioritizing the backlog, aligning stakeholders, overseeing delivery, and ensuring adoption.

For regulated or sensitive areas, privacy and compliance experts should be involved early. This prevents governance issues from appearing late in the process and delaying delivery.

The pod model does not need to be introduced across the entire organization at once. It can start with a few high-value use cases, demonstrate results, and then scale gradually.

Building a Core Reporting Backbone

Many organizations lose valuable capacity by repeatedly building similar dashboards for different teams.

One business unit may create a sales report, another may create a slightly different version, and a third may build its own view using different definitions. The same pattern often appears across finance, operations, customer, supply chain, and product reporting.

A core reporting backbone helps reduce this duplication.

This means defining a standard set of enterprise dashboards, metrics, and datasets that serve the majority of recurring reporting needs. These reports should be built on trusted data, agreed definitions, and consistent governance.

A strong reporting backbone gives the organization a common language for performance. It also helps prioritize delivery. Requests that improve or extend core reporting can be prioritized, while highly local or low-value requests can be directed toward self-service.

This approach does not remove the need for local analysis. Business teams still need flexibility. However, they should be building on a trusted foundation rather than recreating the same reporting logic in different places.

Focusing on Time-to-Insight

Traditional delivery models often focus on completing the requested deliverable. But a more important question is whether the business receives the insight in time to act on it.

A dashboard delivered after three months may be technically correct, but it may arrive too late to influence the decision it was meant to support.

Organizations need to focus on time-to-insight.

Not every request requires a fully industrialized dashboard. Some needs may be met through a quick analysis, a certified dataset, a prototype, or a self-service report. The delivery approach should match the urgency, value, and risk of the decision.

For high-risk reporting, such as financial, regulatory, or sensitive customer data, stronger controls may be necessary. For low-risk exploratory analysis, a lighter delivery path may be more appropriate.

The key question should be: what is the fastest safe way to help the business make a trusted decision?

Treating Self-Service as a Spectrum

Self-service analytics is often presented as a simple choice. Either the central data team delivers everything, or business users are left to build everything themselves.

In reality, self-service should be treated as a spectrum.

Some users only need access to standard dashboards. Others can create reports from certified datasets. More advanced users may work with governed data marts, semantic models, or approved analytics tools. A smaller group may be trained to perform deeper analysis or build local dashboards within defined guardrails.

The level of freedom should match the user’s capability and the risk of the data involved.

Low-risk analysis can move with lighter controls. High-risk reporting, regulatory data, sensitive customer information, or enterprise-level metrics require stronger governance.

Self-service should not mean uncontrolled reporting. Without proper guardrails, it can lead to duplicated dashboards, inconsistent metrics, and compliance exposure. Successful self-service requires certified datasets, role-based access, metadata, clear ownership, training, and support.

Designing Governance Into the Data Environment

Governance should not be treated only as a final approval step. If every request has to pass through heavy stage gates, governance becomes a bottleneck. At the same time, removing governance entirely creates risk.

A better approach is governance by design.

Controls should be built into the data environment from the beginning. This includes role-based access, data classification, metadata tagging, approved definitions, lineage, privacy controls, and certified data products.

This allows users to explore and analyze data safely within defined boundaries. Low-risk work can move through lighter pathways, while high-risk use cases receive more formal review.

The principle should be simple: apply the level of governance required by the risk, but no more than necessary.

This approach helps organizations maintain trust and accountability without slowing down every request.

Making Existing Assets Visible

A major source of inefficiency is lack of visibility.

Teams often build new dashboards, datasets, or reports without knowing that similar assets already exist elsewhere in the organization. This leads to duplication, inconsistent reporting, and wasted capacity.

Creating an internal catalogue of dashboards, datasets, reports, and data products can help solve this problem.

The catalogue should be searchable and easy to use. It should show what exists, who owns it, what data it uses, whether it is certified, and how it should be interpreted.

This encourages reuse and helps teams connect with existing owners before starting new development. It also gives the central data function a clearer view of demand patterns and opportunities to consolidate reporting.

Repositioning the Central Data Team

To reduce BI and AI bottlenecks, the central data team cannot remain the only delivery engine. It must become an enabler of scalable data use.

This means focusing central capacity on the work that truly requires enterprise-level expertise. That includes core reporting, strategic data products, governance standards, data platforms, semantic models, and high-value AI and analytics use cases.

Business teams, meanwhile, can take greater responsibility for local insight generation within governed boundaries.

This creates a hub-and-spoke model. The central team provides the foundation, standards, platforms, and controls. Business teams use that foundation to answer more of their own questions safely and consistently.

Done well, this model allows organizations to scale analytics without losing control.

Conclusion

BI and AI delivery bottlenecks are rarely caused by demand alone. They are usually caused by unclear intake, weak prioritization, fragmented ownership, duplicated reporting, and governance models that do not scale.

The answer is not simply to add more people or push more work through the same central queue. Organizations need a stronger operating model.

Based on insights from Kamal Yadav, Principal Data and Insight Analyst at Brambles, the path forward involves separating run and build work, creating a dedicated intake function, using product-centric delivery pods, building a core reporting backbone, enabling governed self-service, designing governance into the data environment, and making existing assets visible.

The ultimate goal is not to deliver every dashboard faster. The goal is to help the business reach trusted insight quickly, safely, and consistently.

 

New Delhi [India], March 10: In India’s evolving corporate landscape, high-value transactions are no longer rare events. Insolvency resolutions, mergers and acquisitions, strategic stake sales, shareholder exits, IPO-linked restructuring, and court-monitored corporate actions are now a regular part of doing business.

Yet in many such transactions – especially under IBC, M&A, and complex restructuring frameworks – the biggest risk is not valuation or negotiation. It is information asymmetry.

An often-overlooked dimension of this asymmetry is access to price-sensitive information within organisations. Recent actions by regulators, such as SEBI, against large consulting firms for information leaks within group entities underline how serious this risk has become. While enforcement is increasing, organisations themselves must demonstrate intent by adopting stronger controls.

Using a dedicated external data room, rather than informal collaboration tools such as shared drives or internal servers, sends a clear signal of compliance, governance, and professionalism. Globally, this is already standard practice and Indian organisations are rapidly moving in the same direction.

From Ethics to Efficiency: Why Structure Matters

Beyond governance, efficiency is a decisive factor in high-stakes corporate transactions. In reality, critical information is often scattered across regulatory filings, financial statements, contracts, litigation records, compliance reports, and historical disclosures, making it difficult for stakeholders to form a clear, unified view. When data is fragmented, decision-making slows and risk increases. Strong outcomes require information that is complete, current, well-structured, and instantly accessible. This is where a structured Virtual Data Room like Right2Data delivers measurable impact.

India’s Best Virtual Data Room: Right2Data VDR

Right2Data VDR was born from client demand within the Right2Vote ecosystem, where users sought a secure, structured platform to manage sensitive transaction data beyond e-voting processes.

Right2Data evolved as a natural extension of Right2Vote, widely used in India’s IBC resolution ecosystem for over a decade. Founded by Neeraj Gutgutia, a Chartered Accountant and IIM alumnus with extensive CFO-level leadership experience, the platform was built on strong governance and security foundations. As transaction complexity increased, clients required a secure Virtual Data Room to manage due diligence and restructuring data. Rohan Randery, an IIM graduate and entrepreneur, joined as Co-Founder to scale operations and strengthen strategic growth.

Today, Right2Data was largely driven by IBC-related use cases, the platform has since evolved into a premium transaction intelligence solution, now increasingly used for M&A, restructuring, IPOs, strategic investments, and due diligence.

What Right2Data Does

Right2Data consolidates, structures, and safeguards critical information in high-stakes corporate transactions, ensuring multiple stakeholders access accurate, secure, and well-organised data within a controlled Virtual Data Room environment.

Whether the transaction involves:

  • an IBC resolution process
  • a merger or demerger
  • a stressed-asset acquisition
  • due diligence or fundraising
  • a strategic investment or corporate restructuring

In an IBC resolution under the Insolvency and Bankruptcy Code, 2016, resolution applicants must review financial statements, litigation records, claims data and compliance filings within strict timelines. In mergers or fundraising rounds, investors evaluate contracts, cap tables, regulatory approvals, and historical disclosures. When this information is scattered across emails and shared drives, confusion and risk increase. Right2Data centralises these materials into a structured Virtual Data Room with role-based access, audit trails, and watermarking creating a single source of truth that connects financial, legal, and regulatory insights seamlessly.

The result is faster decision-making, reduced transaction risk, stronger compliance posture, and greater confidence among promoters, lenders, investors and advisors navigating complex corporate events.

By bringing legal, financial, regulatory, and transactional data into a coherent structure, decision- makers gain clarity under tight timelines. At the same time, the use of an auditable external platform ensures compliance, traceability, and control at every stage of the transaction.

Key Risks in Corporate and Financial Transactions

High-stakes corporate transactions rarely fail because of strategy alone. More often, they are delayed, disputed, or weakened due to preventable information risks. When data is fragmented or poorly governed, uncertainty increases, trust erodes, and execution slows. In regulated environments, these weaknesses can escalate into legal exposure, valuation erosion and reputational damage.

The most common and dangerous risk factors include:

  • Critical data that exists but is poorly organised or incomplete
  • Limited visibility across legal, financial, and regulatory dimensions
  • Heavy reliance on manual collation and fragmented advisor inputs
  • Late discovery of hidden liabilities, encumbrances, or pending disputes
  • Leakage of price-sensitive information due to uncontrolled or informal access

In processes under the Insolvency and Bankruptcy Code, 2016 (IBC), compressed statutory timelines magnify these risks. Resolution applicants, lenders and advisors must make high-value decisions quickly often while multiple versions of documents circulate through emails, shared drives or unsecured channels. A single overlooked clause or data leak can alter deal outcomes or trigger regulatory scrutiny.

Right2Data mitigates these risks by creating transaction-ready Virtual Data Room environments with structured folders, audit trails, watermarking, and role-based access controls transforming vulnerability into compliance, clarity and controlled execution.

What Sets Right2Data VDR Apart

Clients value not just the technology, but the way Right2Data partners with them during high-pressure transactions. Beyond software features, the platform delivers responsiveness, cost-efficiency, and regulatory alignment, critical factors when sensitive information, tight timelines, and multiple stakeholders are involved in complex corporate processes.

High-Touch Customer Support

Corporate transactions often move under intense time pressure, where even minor delays can affect valuation, negotiations or compliance deadlines. Right2Data provides responsive, hands-on assistance through dedicated support teams who understand transaction workflows, not just technology. This ensures quick issue resolution, smoother onboarding, guided document structuring, and continuous coordination during critical deal phases.

Most Affordable and Accessible

Many global virtual data room providers operate on high-cost models designed primarily for large multinational deals, often relying heavily on automated or chatbot-driven support. Right2Data offers a cost-effective alternative tailored for Indian market realities, enabling mid-sized companies, resolution applicants, investors, law firms and advisors to access enterprise-grade level security and structure without prohibitive pricing barriers.

Data Hosted on Indian Servers

With evolving regulatory expectations and increasing scrutiny over sensitive financial and personal information, data sovereignty has become a serious consideration. Right2Data.in hosts all transaction data on Indian servers, aligning with compliance expectations and the principles of the Digital Personal Data Protection (DPDP) Act. This strengthens control, enhances regulatory comfort, and reinforces trust in high-stakes corporate environments.

Who Uses Right2Data

Right2Data is trusted by professionals who operate in environments where accuracy, confidentiality, and time-bound execution are non-negotiable. These are decision-makers responsible for managing sensitive financial data, regulatory disclosures, and high-value negotiations. For them, a Virtual Data Room is not just a storage tool, it is a control mechanism that shapes deal confidence and credibility.

Right2Data works closely with:

  • Resolution professionals and stressed-asset investors managing IBC-driven processes under tight statutory timelines
  • Promoters, boards and CFOs navigating restructuring, stake sales, strategic exits, or capital raises
  • Legal advisors, investment bankers, and financial consultants handling due diligence, compliance reviews, and complex mandates
  • Listed companies, startups, and growth-stage enterprises preparing for fundraising, M&A, or corporate actions

Clients such as BOB Capital, JC Flowers, Ernst & Young, and Axis Capital, along with independent resolution professionals and emerging enterprises, rely on Right2Data for structured execution and dependable support. Their experience typically highlights three factors: intuitive navigation even for first-time users, responsive human assistance during critical phases and strong control over document access and tracking.

Turning Data into Transaction Confidence

In high-stakes corporate transactions, speed may initiate momentum, but confidence sustains it. Decision-makers need clarity on liabilities, contracts, regulatory exposures and financial performance before committing capital or approvals. When information is structured, searchable, and securely hosted within a controlled environment, uncertainty reduces significantly.

Right2Data helps stakeholders transition from fragmented email trails and scattered folders to a unified, auditable data environment. Instead of reacting to last-minute document requests or version confusion, teams operate with preparedness and transparency. Some organisations adopt secure Virtual Data Rooms only when mandated by advisors or regulators. Others recognise early that proactive structure reduces disputes, accelerates diligence, and strengthens negotiation positions. The difference is not just compliance, it is transaction confidence built on organised, accessible, and controlled information.

If you are involved in IBC, M&A, restructuring, or strategic corporate actions, the quality and custody of your data can shape the outcome.

In complex corporate transactions, the strength of decisions depends on the strength of information governance. As regulatory scrutiny increases and transaction timelines tighten, structured and secure data environments are becoming less optional and more foundational. Platforms like Right2Data reflect a broader shift in Indian corporate deal-making toward control, clarity, and compliance by design.