On August 1, NEC added a department whose internal roles were all assigned to AI. The Japanese technology group announced the change nine days later. Its Corporate AI & Workforce Department had a division head, a board with executive functions, managers and employees. People retained final evaluation, decisions and control over quality, according to NEC’s announcement.

July’s internal test preceded the formal department. NEC said a particular set of management analysis, simulation and risk-detection tasks took about one-seventh of the previous time. The company did not present that result as a sevenfold improvement across its roughly 100,000 employees.

News coverage quickly found the human image inside the software. Yonhap reported an initial roster of 17 agents, with names and specialties that included sales support and extracting tasks from meeting records. Seventeen makes an accessible headline. It tells a reader very little about capacity.

An agent can run intermittently, handle multiple assignments or generate another agent for a new task. A roster does not reveal how many reports people accept, how much work needs correction or how long a human waits for an answer. It also omits the people maintaining the environment around the software.

That surrounding work appears in NEC’s own design. When the agents encounter problems they cannot resolve internally, requests go back to people. Data, access permissions and missing business context still have owners elsewhere in the company.

Putting a recognizable department around automated work makes the handoffs easier to examine. A request enters the unit, produces an output and sometimes returns with unfinished work. Following that assignment reveals more about capacity than counting the software roles.

A finance director considering a similar arrangement first has to decide which workload belongs in the new department, and which people must remain available when it returns a question.

Four software layers around a business assignment

Daily lead times and token bills reach the AI division head. NEC’s four-page description of the department assigns responsibilities across four software layers, including the employees who perform the tasks.

LayerAssigned responsibility
AI division headMonitor overall activity, lead time, AI cost, quality and risk alerts; report to human management
AI boardConsider proposals from different executive perspectives and decide improvements within its scope
AI managersManage output quality, operating conditions and token consumption
AI employeesExecute assigned work, including producing analysis for a management dashboard

A familiar chart makes the assignment easier to follow. Work enters a department, gets allocated and returns for inspection, while management watches the operation as a whole.

The expenses behind the titles differ. Human management requires salaries and meeting time; software coordination requires model calls and evaluation work. An extra layer should improve the completed assignment enough to justify those expenses.

Consider an illustrative assignment to compare regional sales performance. Separate agents could examine different regions at the same time, each with its own documents. A coordinating agent could assemble the findings and identify inconsistencies. That division of work has a practical reason: several independent searches can proceed together.

Now change the assignment. Every region uses a different definition of a qualified opportunity, so searching faster cannot settle the comparison. Someone must establish a common definition, or preserve the differences in the report. Another AI manager may make the disagreement visible; it cannot authorize a new commercial definition.

In a June 2025 account of its research architecture, Anthropic described a lead agent coordinating parallel research agents. The company found that this structure helped with broad searches.

Anthropic also reported that its multi-agent systems used about 15 times as many tokens as chat interactions. Tasks with tightly coupled dependencies or shared context could fit the architecture poorly. Those observations concern a particular research system and an older model generation. They do not supply a current cost estimate for NEC.

For NEC, the corresponding test would concern each layer’s contribution. Improved results can justify extra computation. Repeatedly passing the same instructions through software managers may instead add avoidable cost.

A buyer can compare those alternatives without settling an argument about artificial intelligence. Give a fixed workflow, one agent and a coordinated group the same assignment. Count accepted results, total cost and elapsed time. Include the interventions each version needs.

Choosing between those arrangements requires a completed assignment. The agent count can help an engineer explain the implementation, but a finance director also needs the workload and expense attached to it.

Nor does an AI board acquire the authority of a corporate board of directors. NEC’s language describes executive functions inside an operating system, with people retaining final decisions. A finance team may accept an automated explanation of a revenue variance while rejecting the proposed budget response. Producing the explanation and authorizing the response remain separate jobs.

July’s speedup stops short of a labor budget

NEC’s July trial supplies its clearest reported performance result. The announcement identifies the work and its time reduction, but omits the full cost boundary, sample size and a detailed quality comparison. A buyer would need those details to price a replacement service.

Elapsed time and labor effort can move differently. Parallel work can finish earlier while consuming more total computation. A draft can arrive quickly and wait for review. An analyst can spend less time preparing a report but more time establishing whether its inputs are comparable.

A simple illustration shows the difference. These are invented planning assumptions, not NEC measurements. Suppose a weekly analytical workload previously required 70 hours of preparation and 10 hours of review. Give the automated version a favorable starting assumption: preparation falls to 10 hours.

Now suppose review takes 18 hours and data repair adds 12 hours. The completed workload uses 40 human hours instead of 80.

Weekly workloadExisting processIllustrative AI process
Preparation and operation70 human hours10 human hours
Review and acceptance10 human hours18 human hours
Additional data repair and rework0 additional hours12 human hours
Total human effort80 hours40 hours
Labor cost at an assumed $60 per hour$4,800$2,400
Additional AI operation and allocated setup cost$0$1,000
Total within this illustrative boundary$4,800$3,400

Under those assumptions, preparation falls to one-seventh, human effort falls by half and total modeled cost falls by about 29%. None of these percentages estimates NEC’s savings. Changing review, repair or tool costs changes the answer.

The $60 hourly rate and $1,000 expense are illustrative inputs. The latter includes incremental operating costs and allocated setup spending. A real comparison would use the company’s own costs, include existing expenses that change and check for double counting.

The repair bill deserves particular care. If the hypothetical 12 hours fix a recurring data problem once, charging those hours to every subsequent report would make the AI process look artificially expensive. Other teams might benefit from the corrected records too.

Conversely, if the same problem returns every week, treating the first repair as a setup cost would understate ongoing labor. The distinction can be checked by following the correction into the following reporting cycle. Cost allocation should reflect what happened, even when that improves the AI system’s case.

Saving those 40 hours across several people would not automatically eliminate a position. The hours may arrive in fragments or at times when another assignment cannot use them. Staff might instead clear a backlog or examine a problem that previously received little attention. Reducing overtime could also produce a measurable benefit. Finance would need to record which outcome occurred.

Suppose a controller receives a report on Tuesday instead of Friday. If the underlying data are sound, that earlier arrival could allow a purchasing decision before a deadline. If approval still waits for a monthly meeting, the same speedup may produce no earlier business action.

For that controller, the relevant timestamp is the accepted decision. Stopping the clock at the generated document would miss the remaining wait.

Faster completion of an important analysis could justify NEC’s system even without a reduction in headcount. A company might willingly spend more to detect a problem earlier.

An operating review should say which result management is buying. Spending more to detect a problem earlier requires different evidence from spending less to produce the same report.

The requests return to finance and IT

Each week, NEC’s design calls for the AI employees to report operating problems and suggest improvements. Issues involving data, permissions, knowledge or context can return to people. Calling this process a survey describes how requests are collected; it does not establish that software experiences engagement or dissatisfaction.

At these handoffs, the software depends on departments whose priorities it does not set.

Imagine the regional sales analysis again. This is an illustrative workflow, not an observed NEC incident. The AI team has completed its first pass and flagged conflicting account classifications. Finance understands the reporting categories. Sales operations knows why particular accounts were moved. IT can change access, but it cannot decide which commercial interpretation is correct.

Finance, sales operations and IT may each already have a full schedule.

If the new department reports only its own model spending, its cost appears modest. If it records every question as a successfully identified issue, its operating dashboard may look productive. The recipient departments experience another intake queue.

Finding that inconsistency earlier could prevent a bad decision. Resolving it still requires an owner and time on a calendar.

An implementation team could begin with a practical agreement. Finance accepts responsibility for reporting definitions. Sales operations maintains commercial context. IT handles access changes within an agreed scope. The AI department owns the quality of the request it sends.

The request itself should reduce work. It can identify the conflicting records, show the two interpretations and explain which downstream result depends on the answer. Sending a vague request to improve data quality merely relocates the original ambiguity.

Finance and IT should also be able to decline. A correction may cost more than the decision warrants, or a permission request may expose information unnecessary for the job. A missing field may reflect a deliberate boundary rather than neglected administration.

Without that ability to negotiate scope, centralization can turn every software preference into a human obligation.

Departments may also refuse useful requests because the benefits accrue elsewhere. Finance supplies context, but another business unit gets credit for the faster forecast. A shared workload can stall because the organization’s incentives still follow separate budgets.

For one selected workflow, a manager can assign a small amount of capacity, record the requests and review whether the results justify that commitment. A narrow initial agreement is easier to change than a company-wide reorganization.

Employees can judge the arrangement against their own task lists. A promise that automation will free their time means little if review work arrives without an old responsibility disappearing.

Experienced analysts could spend less time collecting inputs and more time investigating unusual movements, while a newer employee loses the preparation work through which they were learning the business. Both experiences can occur in one department. A task-level time saving does not capture the resulting choice about how people develop.

For the newer analyst, reviewing a finished answer is not the same exercise as building an explanation from raw records. A manager could preserve that learning through a different assignment: compare the generated report with its sources, identify a disputed definition and defend the chosen treatment.

That exercise takes supervision. Someone experienced must explain why one apparent discrepancy matters and another does not. If a department plans to grow its own future reviewers, those teaching hours belong in its staffing plan. Faster preparation creates an opportunity to change the training task; it does not design the replacement lesson.

An AI manager faces a different promotion test

James Simpson, Deborah Richards and their coauthors tested AI leadership in a peer-reviewed study published in March 2026. Teams performed a collaborative search task in a multiplayer game. Their leader was either a human drone operator, a rule-based AI operator or an operator built with a fine-tuned language model.

Human-led teams performed better overall. The language-model operator achieved comparable containment performance on one measure, but its teams did not complete trials under fog conditions.

The game’s results cannot establish how AI would perform at NEC or in financial analysis. They caution against treating success on one task measure as evidence of reliable coordination under different conditions. A software manager that allocates work among agents would need a separate evaluation before directing people.

A manager buying software can apply that caution without reproducing the experiment. Test what happens when the assignment is incomplete, when two inputs disagree and when a participant knows something absent from the shared record.

Those situations need not be exotic. A sales forecast may depend on a customer conversation that has not reached the database. A delivery estimate may omit a supplier’s warning. An employee may know that the apparently idle team is handling an unrecorded emergency.

A system that produces tidy plans from complete inputs has passed only one part of the management test.

Human managers also negotiate priorities between people who have different obligations. They can explain why a team should accept an inconvenient assignment or why a deadline should move. They make commitments that other people remember.

Giving software a manager title does not establish that it can perform those jobs. Nor does it prevent the software from helping a person perform them. Separating the responsibilities permits a more useful design than treating management as one indivisible occupation.

The organizational gap appears in Kyndryl’s June 2026 People Readiness Report. Its survey covered 1,100 business and technology leaders across eight countries. Fifty-seven percent reported broad deployment or integration of AI into core processes. Only 23% considered their workforce fully ready.

Just 32% said they had achieved at least one of their two main AI goals; 11% reported achieving both. CIO Kim Basile and chief human resources officer Mark Paulek connected the findings to changes in roles, skills and how work gets done.

These are leaders’ self-reports from a services vendor’s study. They do not measure NEC’s readiness, establish a causal effect of organizational redesign or justify extrapolating the percentages to every employer.

Buying capability and preparing people to use it remain separate projects. A company can complete the purchase while leaving employees unsure how their responsibilities have changed.

For the employee, preparation should include a clear account of what success now means. If AI prepares the first analysis, does promotion reward the volume of reports reviewed, the importance of errors caught or better decisions supported?

Counting approvals can encourage fast acceptance; counting errors without considering severity can encourage unnecessary corrections. A manager needs to understand the business result well enough to judge whether the intervention helped.

That work may justify a changed job description. It does not require renaming everyone an AI manager.

Informa’s AI chief starts with the meeting

On August 7, Amin Mrini, Informa’s chief commercial AI officer, discussed a familiar office task in an interview with aibl. Making a presentation faster, he argued, changes little if the decision still waits for the same monthly meeting.

His starting point was the judgment people must retain. Work could then be arranged around those decisions, with suitable tasks delegated to software. He also described small engineering teams embedding AI into existing work.

Mrini used invoice reconciliation to make the tradeoff concrete. Suppose people currently handle the hardest 20% of cases. What would the team look like if AI could take on half, or most, of those exceptions? He was posing a design question, not reporting those results at Informa.

The remaining cases could demand more expertise per case. Cutting the queue in half would not necessarily cut the attention needed for each item. An experienced reviewer might deal with fewer invoices and spend more time on each unusual one. A headcount plan based only on transaction volume would miss the change in difficulty.

Mrini was explaining his operating approach, rather than presenting an independently measured outcome. His starting point offers a way to consider NEC’s design from the receiving team’s perspective.

An employer might first change the decision schedule, simplify the required information or remove an approval that no longer serves a purpose. Automation could follow. The resulting organization might contain a central AI team, embedded specialists or no separate AI department at all.

For a recurring reporting task with shared definitions, centralizing the work could reduce duplication. One group maintains the connection to the source system and improves the common process. A correction benefits several teams instead of remaining inside one person’s instructions.

For an assignment that depends on local judgment, distance can be expensive. A commercial team may spend more time explaining a customer’s situation to the central service than it previously spent preparing the first draft itself. Embedding a specialist could keep interpretation close to the people responsible for the result.

A central unit can create a queue, while embedded teams may rebuild similar tools and compete for the same scarce engineering time. One actual assignment gives the company a way to compare those costs before deciding where the reporting lines belong.

Consider a hypothetical company preparing proposals for several customer segments. Its sales leaders want earlier drafts, but each segment has different contract practices and delivery limits. A central team can assemble common material and check required sections. Local staff still determine which promises the company can make.

If the central service returns a polished proposal containing an impossible delivery date, the sales team must repair it. If local teams independently maintain every technical description, inconsistent information can reach customers. The organizational design must handle both problems.

One option is to centralize reusable material and keep commercial commitments with the segment owner. Another is to embed an engineer temporarily, improve the local workflow and then transfer maintenance to a shared team.

Once the customer receives a usable proposal, the buyer can compare its cost and turnaround with the alternatives. The corrections and customer responses help explain any difference.

Starting with that proposal keeps the organizational chart attached to a job. Before staffing or naming a department, the buyer has an assignment whose cost and quality can be compared.

NEC’s separate department gives scattered automation a shared home. A business has somewhere to send an assignment and ask about its status. Management can compare operating conditions across the work instead of relying on individual employees’ demonstrations.

A dedicated unit can also preserve improvements when an employee changes roles. A useful method need not remain in one person’s chat history. That is a plausible organizational benefit even before any headcount changes.

Centralization could eventually reduce the human requests discussed earlier. Once a shared team resolves a recurring definition problem, several workflows can reuse the answer. The relevant test would be whether repeat requests decline as the service learns, rather than whether the first month contains any requests at all.

Scale changes that calculation. A hypothetical twenty-person business may have no separate finance analyst or internal IT team. Its founder handles priorities while outside providers maintain accounting and software. Copying a large company’s departmental chart could create more coordination work for the founder.

That smaller company might start with one recurring workload and a named person who accepts the result. It could add coordination software when simultaneous assignments actually exceed that person’s capacity. NEC’s experiment can inform the decision without supplying an organizational chart that every company should copy.

Centralization becomes harder to justify when it adds explanation work to every interaction. A local analyst should not have to write an elaborate brief for a simple task that they already understand.

Assignments can move back. If context proves difficult to transfer, the company may return parts of a shared workflow to a business team. The department can earn its place through assignments that customers continue to send.

NEC has a services business to protect

Before the department opened, NEC had already made internal experimentation part of its commercial plan. Its May 12 management plan described turning the company’s own transformation experience into repeatable offerings within the BluStellar business.

For BluStellar, NEC reported revenue of ¥705 billion and a non-GAAP operating margin of 14.5% for the fiscal year ending March 2026. The targets for the year ending March 2031 were ¥1.3 trillion and 25%, excluding the impact of acquisitions.

Those business-level figures cannot be attributed to the AI department. They do give the internal experiment a commercial setting: NEC needs methods that can be taught and supported at companies that do not share its internal knowledge.

Investors raised price pressure in the May 12 session accompanying the plan. President and CEO Takayuki Morita, CFO Kunikazu Amemiya and strategy chief Ikuo Matsuhashi attended. The published answers are not attributed individually.

Asked about AI-related price pressure, NEC said it expected to pass some cost reductions to customers while lowering its own costs. It also emphasized selling systems on the value delivered. The company expected fuller benefits from internal AI efforts from the fiscal year ending March 2028 onward.

A customer can accept that software accelerates delivery and still ask why the bill has not fallen.

An implementation vendor must pay for specialists who understand the customer’s systems, assemble the workflow and maintain it as the business changes. A buyer may see the software performing the visible task and assume that most of those costs have disappeared. Measuring the entire internal workload would help the vendor explain which expenses remain and which results merit a premium.

Suppose the customer purchases a reporting service. A faster draft could support a lower price if the service costs less to deliver. A more reliable forecast could support a higher price if it improves a consequential decision. The contract should identify which result the buyer expects.

Without that distinction, both sides can talk about productivity while negotiating different things. The buyer wants a discount for automation. The seller wants a premium for improved decisions.

NEC’s relationship with Anthropic adds another part of the business model. In an April 24 announcement, Anthropic said Claude would be made available to approximately 30,000 NEC Group employees worldwide. The collaboration included engineering and industry-specific products for Japanese customers.

The 30,000 figure describes planned access, not measured active usage. Neither that announcement nor the department’s description identifies the August unit’s model stack; the partnership alone cannot establish it.

A services company can combine its own methods with tools from outside suppliers. It can also become dependent on changing supplier prices, capabilities and product terms. Those dependencies belong in the economics of a repeatable service.

A prospective customer can also ask how much of the demonstration relies on knowledge that NEC already possesses about itself. An internal team may know where the data lives and how executives interpret a particular measure. A customer installation must acquire that knowledge, even when the software transfers easily.

With a repeatable offering, accumulated experience should reduce the work needed for another installation. Otherwise, a polished internal demonstration may still lead to a largely bespoke customer project.

Bespoke work can be worth buying. A customer with unusual reporting rules or old systems may need experienced implementation staff more than it needs a standardized product. The objection is to selling the project as effortless replication while leaving that work out of the proposal.

For NEC, an honest account of the human effort could strengthen the commercial case. It would show a buyer where the provider’s specialists earn their fee and which tasks the customer must still staff. A clear division of work can be more reassuring than a larger claimed automation percentage.

A buyer can ask for evidence from a workflow resembling its own. That evidence could show the time spent establishing definitions, the people needed after launch and the quality of accepted output. It should distinguish reusable product capability from customer-specific effort.

NEC’s internal department is a place to learn those distinctions. Whether the learning produces a profitable service remains a separate test.

A department budget that counts the people outside

Follow one completed assignment from the team that needed it to the people who helped deliver it. For the first six weeks of a pilot, a company could use the sheet below. This is an original planning framework, not NEC’s reporting system. Six weeks is illustrative; a slower business cycle may require longer observation.

Work or result to recordWhere to measure itDecision it supports
Accepted business outputReceiving team, after correctionsWhether the service completes useful work
Preparation, review and repair timeEvery human team involvedWhether work disappears, changes or moves
Model, tool and setup expenseAI operation and finance recordsWhether the full service merits its cost
Queue time and missed deadlinesFrom initial request to accepted resultWhether faster generation advances the business
Defects, repeated requests and reversalsReceiving team and service ownerWhether output quality holds beyond a demonstration
Use of any released timeEmployee workload and manager reviewWhether capacity becomes a concrete benefit

Start with the team receiving the report. Does it use the result, correct it or reject it? A rejected report can teach the developers something, but it belongs in the rework record.

Then follow the corrections. If finance spends an hour clarifying a definition, that hour belongs to the workload even though finance sits outside the AI department.

Operating cost should include the method of allocation. A team experimenting with one report may absorb a setup expense that later supports many reports. A pilot that looks expensive at low volume could become economical. A pilot that looks cheap because setup was paid elsewhere could do the opposite.

Queue time supplies another check. A service might generate ten drafts in an hour and wait two days for a reviewer. Scaling generation would increase the waiting pile. The capacity constraint would be the review process.

Hiring another reviewer is one response. Improving requests or reducing defects could also clear the queue. Before expanding capacity, the receiving team should decide whether it needs every report being produced.

Include the practical alternative: the old process, a simpler automation or no report at all. An unnecessarily elaborate manual process makes the new system look better than a credible alternative would.

Keep the timing comparable as well. A quiet week and a quarter-end close create different workloads. A trial that avoids the difficult period may establish that the software runs, while leaving the staffing question unresolved. The team should carry the same record through the period when employees expect the most exceptions.

Employees should help establish that comparison. They often know which apparently necessary steps already receive little attention and which small checks prevent costly mistakes. A process diagram alone may miss both.

For a manager, the resulting discussion concerns staffing and work design. For a vendor, it concerns the cost of delivering a service. For a customer, it concerns the result worth buying. Keeping those views in the same review reduces the chance that one party’s savings become another party’s unexplained workload.

Return to the illustrative regional report. The agents have found two incompatible revenue definitions. The report is ready except for that choice.

A finance controller can reconcile the definitions, preserve both with an explanation or ask the regional team to correct its records. The software can prepare the evidence for that decision. The controller still has to make it and spend the time.

Those minutes belong in the department’s cost, even when the controller’s name appears in a different box.


Published August 31, 2026. Company announcements, management targets, experimental results and original planning examples are identified separately. No interviews were conducted for this article.