Cross-Team AI Dependencies: George Dagliyan Research Guide

What problem does a cross-team AI request flow actually solve?

When George Dagliyan’s research themes are applied to enterprise AI, the central issue is not whether one team can use a tool faster, but whether sales, operations, and finance can move one request without losing control of the data, the decision, or the exception path. This article answers a practical question: how to map dependencies so AI helps local work while still improving the full process end to end.

NIST’s AI Risk Management Framework presents AI risk management as voluntary and aimed at trustworthiness considerations across design, development, use, and evaluation. That framing is useful here because a request flow is not just a chatbot task; it is a sequence of handoffs where trust, accountability, and visibility must stay intact.

How should the sales-to-operations-to-finance flow be mapped?

A useful dependency map starts with the request origin, then follows the data, the service, the decision, and the exception. In this brief, sales creates the request, operations evaluates fulfillment feasibility, and finance determines billing or credit treatment. Each step should name four items: upstream data owner, downstream decision authority, service dependency, and exception route.

For example, sales may own opportunity context, customer commitments, and requested dates. Operations may own inventory, capacity, scheduling, and delivery feasibility. Finance may own pricing controls, approval rules, credit exposure, and invoice timing. The map should show where AI assists the preparation of each handoff, not where it silently becomes the decision-maker.

Who owns the upstream data and who holds downstream authority?

Upstream data owner means the team accountable for the data before it is transformed by the AI-assisted request flow. Downstream decision authority means the team that can approve, deny, or override the next step after review. These are not always the same group, and confusing them is a common source of delay and dispute.

A simple rule helps: the group that can correct the source data owns the source data, while the group that can accept business risk owns the decision. In a sales-to-operations-to-finance flow, sales usually owns customer-facing promise data, operations usually owns feasibility data, and finance usually owns commercial control data. The organization can adjust this, but the rule should remain explicit and documented.

Where does AI help most, and where must humans stay accountable?

AI is most useful when it drafts, classifies, summarizes, or compares information that already exists in the workflow. It can help sales prepare a cleaner request, help operations compare the request against capacity, and help finance surface policy checks or missing fields. The risk appears when local productivity is mistaken for end-to-end improvement.

Local productivity means one team finishes a task faster. End-to-end improvement means the whole request reaches a correct outcome with fewer rework loops, fewer handoff gaps, and clearer accountability. NIST’s AI RMF is relevant here because it is designed to improve the ability to incorporate trustworthiness considerations into the use and evaluation of AI systems, not merely speed up isolated tasks.

What service dependencies should be listed before the workflow goes live?

Service dependency means the systems, datasets, or human services the AI-assisted flow relies on to function. In this brief, that includes CRM data from sales, planning or scheduling data from operations, billing or ERP data from finance, and any identity or approval service that determines who can submit or override a request. If one dependency fails, the flow should not pretend the request is still complete.

This is also where provenance matters. W3C’s PROV overview defines provenance as information about entities, activities, and people involved in producing a piece of data or thing, used to assess quality, reliability, or trustworthiness. For a request flow, provenance is the record of where a recommendation came from, which inputs it used, and who accepted or changed it.

Which exceptions must be routed outside the normal AI path?

Exception route means the alternate path used when the request does not fit normal thresholds, fields, or confidence levels. Typical exceptions in this flow include missing customer commitment details, inventory conflict, pricing mismatch, credit concern, or a finance policy exception. The exception route should name the human owner, the required evidence, and the target turnaround condition.

A practical decision rule is simple: if the AI output changes a promise, a shipment, or an invoice and the supporting data is incomplete or disputed, the request leaves the automated path. This is not an official threshold from NIST or W3C; it is a proposed worksheet rule for operational clarity. The goal is to keep exception handling visible instead of burying it inside a generic “review later” bucket.

What worksheet can teams use to separate local gain from end-to-end value?

The worksheet below is a proposed tool, not an official standard. For each request type, list: request owner, upstream data owner, downstream decision authority, service dependency, exception route, AI assistance used, and the end-to-end outcome expected. Then add one column for local productivity and one for end-to-end improvement. The difference between the two columns is often where governance breaks.

Worked hypothetical example, with assumptions: a sales rep submits a rush order change, operations checks capacity, and finance checks invoice impact. Sales is the upstream data owner for the customer promise, operations is the downstream decision authority for fulfillment feasibility, and finance is the downstream decision authority for billing impact. If AI only helps sales write the request faster, local productivity increases; if the same flow also reduces rework between operations and finance, end-to-end improvement occurs.

How can a team test whether the dependency map is working?

A lightweight test plan can use five request cases: one routine case, one missing-field case, one operations-capacity conflict, one finance-policy conflict, and one override case. For each case, reviewers should record whether the source data owner was clear, whether the downstream decision authority was unambiguous, whether the service dependency was available, and whether the exception route was used correctly.

George Dagliyan’s research themes on AI adoption, innovation diffusion, and technology acceptance fit this problem because adoption depends on more than tool availability. The flow spreads only when the people who supply data, approve decisions, and handle exceptions see the process as trustworthy, workable, and aligned with their role. That is the practical difference between a chatbot pilot and a durable operating model.

Frequently Asked Questions

What is the difference between upstream data owner and downstream decision authority in this flow?

Upstream data owner is accountable for the accuracy and completeness of the source information before AI or another service transforms it. Downstream decision authority is the group that can approve, reject, or override the next step based on business risk. In a sales-to-operations-to-finance flow, those roles often differ, and the distinction prevents hidden blame when a request fails.

Why is provenance useful for an AI-assisted request flow?

W3C’s PROV overview describes provenance as information about the entities, activities, and people involved in producing data or a thing. In this workflow, provenance helps show which input fields the AI used, who changed the draft request, and where a decision came from. That record supports trust, review, and correction without assuming the AI output is inherently reliable.

How can a team tell local productivity from true end-to-end improvement?

Local productivity happens when one team finishes its task faster, such as sales drafting a cleaner request with AI. End-to-end improvement happens when the whole request moves through operations and finance with less rework, fewer missing fields, and clearer authority. The difference matters because a faster front end can still create more downstream work.

What belongs in an exception route for this workflow?

An exception route should name the human owner, the trigger for escalation, the evidence needed, and the path to final resolution. Common triggers include missing customer commitments, capacity conflict, pricing mismatch, and credit or invoice concerns. The route should be explicit enough that no team assumes another group will resolve the issue automatically.

How does NIST’s AI Risk Management Framework fit a sales-operations-finance flow?

NIST presents the AI Risk Management Framework as voluntary guidance intended to improve the ability to incorporate trustworthiness considerations into AI design, development, use, and evaluation. For this flow, the useful takeaway is not a rigid template but a risk-managed structure. The map should support clear roles, traceable decisions, and handling of exceptions.

Sources and further reading

• NIST — AI Risk Management Framework
• W3C — PROV Overview