If You Leave It to OpenAI's FDEs, Will AI Adoption Progress? — Five Tasks That Remain for the Customer

The generative AI prototype is working. The next step is production deployment.

However, an expectation has emerged in meetings that "if we bring in OpenAI experts, they will be able to take it from here." It can seem as though a single expert team will take on everything from business selection, data connection, and evaluation to security and deployment to the front lines.

OpenAI's Forward Deployed Engineers (FDEs) are indeed involved in a wide range of processes. However, leaving things to an FDE does not mean that decisions on the customer side become unnecessary.

On the contrary, to work effectively with an FDE, it is necessary to distinguish between what can be decided by technology and what the customer company must take responsibility for deciding.

In this article, we will organize the five tasks that remain for the customer when proceeding with production deployment alongside OpenAI's FDEs.

OpenAI's FDEs are not a role that only builds prototypes

OpenAI's FDE job postings for Tokyo explain that FDEs lead the way with customers through problem discovery, technical scoping, system design, construction, and production deployment.

The scope of responsibility goes beyond simple API connection. They are responsible for technical delivery across multiple deployment projects, from the initial prototype to a stable production system.

Furthermore, the following three points are cited as success metrics:

• Actual use in a production environment
• Measurable impact on business operations
• Feeding evaluation results back into the product and model roadmap

In other words, this is not a job that ends when the code runs. The scope includes ensuring it is used in the field, measuring the results, and connecting those learnings to the next improvement.

This is an example of the current job description published by OpenAI. It is not a definition common to FDEs at all companies.OpenAI "Forward Deployed Engineer - Tokyo"

A wide scope of responsibility is not the same as "being able to decide anything"

When hearing that FDEs are involved from discovery to production deployment, it can feel as though the decisions necessary for adoption can also be left to them.

However, having a wide technical scope is different from having final decision-making authority regarding business or operations.

For example, consider a scenario where an AI agent supports inquiry responses. This is not a case study of an actual company, but a hypothetical example for considering the division of responsibilities.

An FDE can design how to search internal documents, integration with existing systems, access control, output evaluation, logging, and how to shut down in the event of a failure. On the other hand, the following decision cannot be determined by technology alone:

• Which inquiries should be handled by AI?
• Which errors are considered unacceptable in business operations?
• Which tasks still require human approval?
• Who holds the responsibility for responding when accidents or incorrect answers occur?
• What business outcomes are expected in return for the implementation costs?

These decisions require the participation of business managers, business units, legal, security, and information systems departments.

Even in OpenAI's job postings, it is stated that FDEs collaborate with customer engineers and business domain teams, and coordinate internally with departments such as Product, Research, Partnerships, GRC, Security, and GTM. It is not premised on concentrating all judgment in a single FDE.

Five tasks remaining for the customer

Before beginning collaboration with an FDE, the customer must undertake at least five tasks.

1. Choose the business processes to change

Simply saying "I want to introduce AI" is not enough to define the scope of verification.

Whose work is taking time, and on what tasks? Do you want to change quality, speed, cost, or the burden on users? It is the customer's job to select the target business processes and explain the reasons why.

An FDE can translate objectives into verifiable technical challenges. However, they do not act as a proxy for business decisions regarding which tasks should be prioritized.

2. Define unacceptable failures

AI output does not need to meet the same standards for every business process.

The impact is different when the phrasing of a sentence is slightly unnatural versus when contract terms or refund amounts are provided incorrectly.

The customer must define unacceptable errors, conditions that require human verification, and conditions for stopping automated processing. An FDE can then translate these into evaluation specifications, guardrails, approval flows, and monitoring rules.

3. Determine who is responsible for data and permissions

In a production system, the issue is not just "can the data be connected," but "who is allowed to see what."

The required deliverables are not just connection programs. They also include data classification, permission tables, usage purposes, retention periods, and log access scopes.

An FDE can flesh out implementation plans and risks. However, the final decision on whether personal or confidential information may be used is made by the appropriate responsible party on the customer side.

4. Agree on how to measure results

Even if the model's response accuracy is high, it does not necessarily mean business results will be achieved.

If problems such as users not utilizing the tool, increased verification work, or time-consuming exception handling remain, the value of production deployment will be limited.

OpenAI views the success of FDE in terms of production usage, measurable business impact, and feedback based on evaluation. Therefore, the customer must also determine metrics suitable for the target business, such as usage rates, processing time, rejections, and the number of exceptions, rather than just evaluating the model.

5. Decide whether to continue, scale down, or stop

Deployment projects also require options beyond just additional development.

If results are limited, narrow the target department. If risks are high, expand the scope of human approval. If costs or operational burdens do not justify the results, stopping the project should also be considered.

FDE can organize logs and evaluation results to provide material for decision-making. However, the final decision on whether to continue the investment or change the business scope remains with the customer company.

The deliverables to be left behind from collaboration with FDE are not just code

If the division of responsibilities is confirmed only verbally, perceptions may diverge after deployment. Documenting at least the following deliverables makes it easier to discover unresolved issues.

• A problem definition documenting the target business and the issues to be solved
• Evaluation specifications for determining the feasibility of production deployment
• Data usage scope and authorization table
• Operational procedures including human verification and exception handling
• Log and monitoring design to detect quality degradation or failures
• Decision criteria for continuing, scaling down, or stopping
• Responsibility assignment matrix for business, operations, legal, security, and technology

These are not necessarily things that FDE receives from the customer as finished products. They are things that the customer's person in charge and the FDE jointly flesh out through verification and implementation.

In its explanation of "Frontier," OpenAI also states that FDE works alongside the customer team to prepare methods for building and operating AI agents in production environments. It also indicates that a feedback loop, which returns lessons learned from the deployment site to research, is a role of the FDE.OpenAI "Introducing OpenAI Frontier"

Is a completed requirements definition document necessary before calling an FDE?

You do not need to finalize all requirements before consulting with us.

FDEs are also involved in the process of transforming ambiguous challenges into areas that can be technically verified. It is not necessary to have detailed system specifications completed from the start.

On the other hand, if the customer's hypotheses and the person in charge have not been decided at all, the FDE cannot begin verification. At a minimum, the following conditions are necessary.

• There are candidates for business processes you want to prioritize changing
• A person responsible for the business can participate
• The location of data that may be used is known
• There is a path for confirmation with legal and security departments
• There is a person in charge of determining performance metrics

From this point on, the technical scope, prototypes, evaluation methods, production configuration, and improvement methods can be designed in collaboration with the FDE.

Conclusion: What FDEs fill is not the customer's responsibility, but the gaps between processes

OpenAI's FDEs are in a role that connects research results with customer operations, advancing projects from prototypes to production deployment.

However, their value is not in making customer-side judgments unnecessary.

Transforming business objectives into technical challenges. Connecting evaluation results to decisions for production. Feeding back lessons learned in the field into product and model improvements. What FDEs fill are the gaps that arise between these processes.

For the adopting company, decisions regarding business priorities, acceptable risks, data usage, division of responsibilities, and continued investment remain.

If you view an FDE as someone who will 'do everything,' important decision-making will be left in limbo. Only by clarifying 'what we will verify together and who will make the final decision' can you connect an FDE's technical capabilities to production results.

If you would like to confirm the job content, required skills, recruitment and salary information, and differences from FDEs at other companies for OpenAI's FDEs, you can check 'What is an OpenAI FDE? Explaining Job Content, Salary, and Career' in the FDE Journal as reference material for considering hiring or collaborative structures.