Agentic AI and Liability: What Businesses in Bangladesh Need to Know Before Deployment

Artificial intelligence is no longer confined to drafting text, answering prompts, or summarising documents. A more consequential class of systems is now entering real business operations: agentic AI. These systems do not merely recommend. They act. They can send messages, trigger workflows, access databases, negotiate with vendors, route approvals, generate and deploy code, and in some cases move money or alter records with limited or no human intervention. That change in operational authority creates a corresponding change in legal exposure.

For businesses in Bangladesh, this development matters immediately. Financial institutions, telecom operators, startups, e-commerce platforms, manufacturers, logistics companies, and large corporate groups are all exploring AI-assisted or AI-driven automation. The commercial benefits are obvious. Costs may fall. Response times may improve. Customer handling may become faster. Procurement, compliance, HR screening, and internal reporting may become more efficient. But as soon as a system is empowered to act independently within a business environment, the legal analysis changes.

That is the central problem. Most legal and contractual frameworks were designed for software that was passive and predictable. Agentic AI is neither. It introduces autonomy, adaptive conduct, and decision-making within complex business environments that cannot be fully reduced to simple rule-based programming. When that system causes harm, the most exposed party is often not the developer, but the business that deployed it.

Tahmidur Remura Wahid (TRW) Law Firm views this as one of the most important emerging risk areas for companies operating in Bangladesh and across borders. The issue is not only whether AI is useful. The issue is whether your organisation can deploy it in a manner that is contractually protected, technically bounded, operationally supervised, and legally defensible.

Why agentic AI is different from ordinary AI tools

Many organisations use AI today without stepping into full agentic deployment. A chatbot that drafts an email, a model that summarises a contract, or a tool that proposes a due diligence checklist may create errors, but it normally does not itself change the outside world. A human still decides what to do next.

Agentic AI is different because it is built to pursue a goal and execute a sequence of actions in order to achieve that goal. In the source article, the authors distinguish between three broad levels: AI assistants, AI agents, and fully agentic AI systems. Assistants are reactive. They respond to instructions and produce outputs for humans to review. AI agents operate with more independence and can act through external tools or interfaces. Agentic AI represents the highest level, where reasoning, memory, and autonomous decision-making are combined to manage multi-step workflows with minimal human involvement.

A useful legal definition offered in the source text is this: an AI agent is a software system that, after receiving a high-level objective from a human principal, autonomously selects and executes a sequence of external actions through tools, APIs, or system privileges, and adapts those actions based on feedback, without requiring human approval at each step.

That definition matters because it focuses on function rather than branding. It does not matter whether a vendor calls its product a copilot, orchestrator, assistant, platform, or digital worker. The legal question is simpler. Can the system act? Can it decide how to act? Can it continue acting without stepwise approval? If the answer to those questions is yes, the system is functionally agentic and the organisation should treat it as such from a governance and liability perspective.

The legal turning point: from recommendation to delegated discretion

The most important legal shift occurs when the business delegates judgment rather than mere execution. Traditional software follows a script. A procurement system may be programmed to reject invoices above a certain threshold. A payment system may require matching fields before processing. The logic is explicit.

An agentic system, by contrast, may receive an instruction such as “reduce Q3 procurement costs” or “clear low-risk customer complaints within policy” and decide for itself which suppliers to contact, which terms to propose, which information to retrieve, which databases to consult, and which messages to send. That is delegated discretion. And once discretion exists, the business must confront the reality that it cannot fully predict every intermediate step the system may take.

This is why liability becomes difficult. The organisation may not have intended the specific harmful act, yet it created the framework in which the system was permitted to act. From a regulator’s, counterparty’s, or claimant’s perspective, that often makes the deployer the natural target.

What is excluded from agentic AI, and why that matters

The source article also usefully explains what should not be confused with agentic AI.

The first excluded category is recommendation-only systems. These tools may influence decisions, but they do not operate external systems directly. A human remains the decision-maker.

The second is rule-based automation. A static script or decision tree may execute external actions, but it usually does not infer its own plan from a broad objective or adjust its strategy in an open-ended environment.

The third is human-in-the-loop execution at every step. If every consequential action requires human approval, the system resembles an assistant with execution features rather than a genuinely agentic system. The risk profile is very different when humans approve each step instead of merely auditing after the fact.

This distinction is highly practical for businesses in Bangladesh. Many companies wrongly assume they are “safe” because a human supervisor exists somewhere in the workflow. But the real question is whether that human meaningfully approves each consequential step, or whether the human is simply reviewing reports after the system has already acted.

The role of the harness, scaffolding, and orchestration layer

One of the strongest insights in the source article is that agency does not arise from the model alone. It is engineered through the surrounding scaffolding or harness. That scaffolding determines whether the system can plan, remember, call tools, access APIs, use credentials, interact with internal systems, and continue operating across multiple steps.

This point has direct legal importance. Two companies may use the same underlying AI model, but their legal exposure may be radically different. One may use the model in read-only mode to summarise internal policies. Another may connect it to ERP systems, payment rails, customer communication channels, and document repositories with write permissions. The first may face low operational exposure. The second may face substantial financial, regulatory, privacy, and reputational risk.

The source article identifies several key components of the harness:

Planning and execution logic, which creates the loop of interpreting objectives, selecting the next action, invoking tools, and adjusting behaviour based on results.

Tool connections and adapters, which give the system the ability to act in the world through APIs, databases, email systems, browsers, payment services, and enterprise platforms.

Memory and context management, which determine what the system remembers and uses in subsequent decisions.

Constraints, permissions, and gating, which define which tools are available, whether the credentials are read-only or write-enabled, and when human approval is required.

Monitoring, limits, and stop conditions, which can impose cost limits, anomaly detection, confidence thresholds, circuit breakers, and policy-triggered shutdowns.

For legal counsel, this means liability analysis cannot be done at the level of marketing claims. It must be done at the deployment level. The scope of permissions, system connectivity, and approval architecture will usually determine where risk actually sits.

The first liability scenario: harm caused to the deployer itself

A major point made in the article is that when an AI agent causes damage, the deploying business often bears the loss itself. This may include lost profits from mispricing, financial harm caused by incorrect transaction handling, reputational damage from faulty communications, regulatory penalties arising from non-compliance, customer loss, or data loss caused by destructive code or system errors.

In theory, the business may look to the software supplier for indemnity or damages. In practice, many technology contracts sharply limit those remedies. Suppliers frequently disclaim warranties relating to accuracy, fitness for purpose, and reliability. Many contracts exclude consequential or indirect losses, which often include the very losses most likely to matter in an AI failure scenario. Some terms even expressly state that outputs should not be relied upon. In the agentic context, the article notes that this disclaimer logic effectively extends to the system’s actions inside the deployer’s own environment.

This is a critical commercial lesson for Bangladeshi companies signing AI vendor agreements. If the platform is purchased off the shelf and deployed into sensitive workflows without negotiated protection, the business may discover too late that it has assumed most of the downside risk while the vendor has capped or excluded its own exposure.

From a Bangladesh perspective, this may become particularly serious in regulated sectors such as banking, NBFIs, telecom, health services, education, logistics, or e-commerce, where a defective or unbounded agent may trigger not only private financial loss but also scrutiny from sectoral regulators, data authorities, tax authorities, or courts.

The second liability scenario: claims by third parties

The source article also emphasises that agentic AI may harm third parties, not merely the deploying organisation. Examples include biased applicant screening, misleading statements to customers, unlawful use of personal data, and infringement of intellectual property rights.

In those circumstances, the third party usually sues or complains against the deployer, not the model vendor. That is because the deployer is the visible business actor that used the system, integrated it into operations, benefited commercially from it, and permitted it to interact with the outside world.

This issue becomes even more complex when multiple AI systems interact. An organisation may use one vendor’s model, another vendor’s orchestration layer, internal tools from its own IT department, and external APIs from third-party providers. If harm emerges from this combined ecosystem, tracing fault becomes difficult. Yet legal responsibility does not disappear merely because causation is technically complicated.

For businesses in Bangladesh, this is especially relevant in four recurring areas.

The first is customer-facing communication. If an AI agent sends misleading, inaccurate, or non-compliant representations to consumers or business clients, the company may face claims based on contract, negligence, misrepresentation, unfair trade practices, or sector-specific compliance obligations.

The second is employment and HR. If AI-driven screening systems reject candidates unfairly or inconsistently, companies may face reputational harm, discrimination-related claims, or internal governance issues.

The third is privacy and data handling. If an AI agent accesses or processes personal data beyond the authorised purpose, or leaks such data through prompts, external tools, or integrated systems, the deployer may face legal and regulatory consequences.

The fourth is intellectual property. If an agent produces, sends, stores, or deploys content that infringes copyright, reveals confidential information, or improperly uses third-party proprietary materials, the deployer may again be the first defendant.

Why explainability and oversight are becoming legal necessities

The article points out a practical reality that many businesses ignore until a crisis occurs: when something goes wrong, the deployer must explain the system’s conduct to regulators, auditors, customers, or courts. Yet doing so may be extremely difficult where the agent operated through multiple steps, changing plans dynamically in response to feedback, retrieved information, or error states.

This creates a dangerous gap. Businesses are expected to justify outcomes, but the underlying systems may be opaque or only partially traceable. The source text notes that some legal regimes already place transparency and explainability obligations on deployers, including under frameworks such as the GDPR and the EU AI Act.

Even where Bangladesh-specific AI legislation remains underdeveloped, the broader legal logic still applies. If a company cannot explain who configured the system, what authority it had, which data it could access, which actions it took, and why it was not stopped sooner, that weakness may undermine its defence in civil, regulatory, employment, banking, corporate governance, or consumer protection contexts.

This is why governance cannot be postponed until after deployment. It must be built before launch.

A practical governance model: “know your agent”

One of the most useful parts of the source article is its governance framework, described as a “know your agent” approach. The idea is straightforward. Before launching an AI agent, a business must understand what mandate it has, what risks may arise during its lifecycle, what contractual protections exist, and what technical and organisational controls are needed.

For TRW Law Firm, this should be understood as a legal and operational due diligence exercise. The business should not ask only whether the system works. It should ask whether the deployment is legally survivable.

1. Risk assessment and contractual review

Before deployment, the company should identify the worst-case scenarios. What is the maximum harm the system could cause if it misfires? Could it expose confidential information? Could it send binding communications? Could it alter pricing? Could it trigger payments? Could it delete records? Could it produce unlawful customer communications? Could it improperly use personal data?

The source article recommends carrying out a risk assessment, quantifying potential liability exposure, checking whether the contract adequately addresses those risks, and stress-testing the workflows in which the agent may act autonomously.

For Bangladesh-based businesses, this stage should involve legal review of:

Vendor limitations of liability

Consequential loss exclusions

Indemnity scope

Service levels for incidents

Change-control rights for model or system updates

Audit and information rights

Security obligations

Data use and retention terms

Subcontracting rights

Termination rights if the model materially changes

If these issues are not negotiated early, the deployer may end up with minimal contractual recourse.

2. Technical controls and access governance

Once the risk is understood, the business must technically constrain the agent. This is not merely an IT exercise. It is a legal control architecture.

The source article recommends limiting the AI agent’s authority, implementing human-in-the-loop review for high-impact decisions, documenting approvals, preventing access to sensitive systems and critical data files, limiting personal data access according to purpose limitation and data minimisation, mapping all internal and external systems the agent can access, and clearly defining which decisions require human authorisation.

In practical terms, this means:

Read-only access should be the default unless strong justification exists.

Sensitive actions should require stepwise human approval.

Irreversible actions should be blocked or heavily gated.

Transaction caps should be hard-coded.

API scopes should be tightly limited.

Credentials should follow least-privilege architecture.

Testing environments should be separated from live systems.

All high-risk actions should be logged with timestamps and identity trails.

These are not optional enhancements. They are core defensibility measures.

3. Organisational governance and ongoing oversight

The article makes clear that technical controls alone are insufficient. Businesses also need internal ownership, trained staff, incident escalation procedures, monitoring, audit processes, and documented allocation of responsibilities.

From a board and management perspective, a minimum governance structure should answer the following questions:

Who approved deployment of the agent?

Who configured it?

Who monitors it daily?

Who reviews incidents?

Who signs off on scope changes?

Who has authority to suspend or terminate the system?

Which committee or executive function receives periodic reports?

How are lessons from failures captured and implemented?

If no one inside the organisation owns these questions, that itself is a governance failure.

The ten immediate priorities for businesses deploying agentic AI

The appendix to the source article offers a condensed checklist of ten priorities that any organisation deploying agentic AI should address. These include authority boundaries, governance controls, monitoring and audit, vendor contracting, cybersecurity posture, intellectual property and confidentiality controls, records and retention, eDiscovery readiness, jurisdictional mapping, and incident response.

Those ten points can be translated into a practical boardroom framework for Bangladeshi and cross-border businesses.

First, define the maximum authority of each agent and make sure technical limits match the written policy.

Second, create pre-deployment risk reviews, testing standards, and override rights for consequential decisions.

Third, implement real-time monitoring and maintain audit logs that are secure, time-stamped, and usable in investigations.

Fourth, negotiate AI-specific clauses in vendor contracts rather than relying on generic software terms.

Fifth, treat AI agents as potential internal threat actors from a cybersecurity perspective.

Sixth, screen outputs for IP, confidentiality, and data leakage risk.

Seventh, preserve records in line with litigation, regulatory, and business requirements.

Eighth, assume that logs may become discoverable in disputes and build logging strategy accordingly.

Ninth, map every jurisdiction where the agent’s actions have legal effect, not merely where the servers are located.

Tenth, create agent-specific incident response playbooks, including shutdown powers, root-cause review, legal privilege strategy, regulator communication, and customer communication.

That checklist is more than compliance housekeeping. It is the foundation of responsible deployment.

What this means for Bangladesh-based companies today

Many companies in Bangladesh are already using AI in fragments, even if they do not call it agentic AI. Internal support tools, automated customer handling, workflow routing, contract summarisation, candidate screening, reporting, procurement support, and finance operations are all likely entry points.

The risk is that organisations treat these systems as ordinary IT tools when they are actually becoming semi-autonomous business actors. Once that happens, the company must update how it contracts, supervises, documents, and controls them.

In the Bangladesh context, this has implications for corporate governance, banking and financial operations, employment processes, privacy handling, commercial contracting, internal controls, litigation preparedness, and regulatory engagement. It also matters for multinational groups using Bangladesh operations as part of a wider data, service, or decision chain.

A company that deploys agentic AI without governance is not simply innovating. It is assuming unseen legal risk.

How TRW Law Firm can assist

For businesses considering AI-enabled workflow automation or agentic deployment, legal review should occur before the system is connected to sensitive environments. In many cases, the most useful intervention is not abstract legal theory but practical structuring.

Tahmidur Remura Wahid (TRW) Law Firm can assist with:

AI deployment risk assessments

Vendor contract review and negotiation

Liability allocation analysis

Data protection and confidentiality controls

Governance framework design

Approval matrix and escalation architecture

Cross-border regulatory mapping

Incident response preparedness

Board and management advisory support

Internal policy and training material preparation

The legal objective is not to stop innovation. It is to ensure that the organisation remains in control of the innovation it deploys.