Responsible AI innovation starts with the specification

For me, responsible AI innovation begins with making those decisions explicit. That includes understanding the expected outcome, recognizing the system's limits and defining who is accountable for the choices. The more accessible execution becomes, the more attention we need to give to the quality of the request.

On September 20, TechCrunch discussed whether AI industry leaders are willing to slow down. That debate leads me to a question about companies' daily work: how are we deciding the speed of our own projects?

Before executing, ask for a specification

In a NewHack workshop, from 32:31, I shared guidance I find useful for building with AI: ask for the specification first, and only then move to execution. The concern was to avoid a sequence of requests and corrections without clarity about the project's direction.

This specification can begin as a single page. It should explain who will use the solution, which task needs to improve, what information will be available and what will be outside the first deliverable. It also needs to record questions that require a conversation with the team.

AI itself can help organize this document. One possible request would be:

Before building, organize the proposal for this project. Describe the problem, users, necessary data, limits and evaluation criteria. Separate what we already know from assumptions and identify the decisions I still need to make.

Then someone who knows the process needs to review the response. A generated specification can fill gaps with convincing hypotheses. During that review, we discover, for example, whether the information exists, whether the described workflow matches reality and whether the team agrees on the expected outcome.

This care also helps develop people's ability to work with AI. Knowing how to frame a problem, recognize an assumption and assess a deliverable becomes part of the project leader's skill set.

Turn responsibility into observable criteria

Expressions such as “using AI ethically” need to acquire meaning within each application. Who could be harmed by an incorrect answer? How will that person be able to flag the problem? What evidence would make the team stop the test?

One reference for organizing this conversation is NIST's AI Risk Management Framework 1.0. It brings together four functions: governing, mapping, measuring and managing risks. It also calls for clear responsibilities and monitoring throughout the system's life cycle. It is a voluntary reference that needs to be adapted to the context of use.

My proposal for starting this discussion within a company is to answer five questions:

• Outcome: which task should improve, and how will we compare before and after?
• People affected: who will use the solution, and who will experience the consequences of its answers?
• Limits: which decisions remain with the team, and which information may be used?
• Evaluation: which situations need testing, and which failures prevent progress?
• Owner: who monitors the pilot, receives reports of problems and decides whether it should continue?

These answers help turn an intention into commitments that can be checked as the work progresses.

An example: organizing internal requests

Imagine a fictional company that receives requests from several departments and wants to use AI to organize that queue. A generic request to “automate support” leaves room for very different interpretations of what the tool should do.

An initial specification could limit the test to summarizing each request and suggesting the responsible department. The team would continue deciding priorities and confirming routing. Changing deadlines or closing requests would remain outside that scope.

Evaluating the proposal would require gathering examples from different departments, including short messages, incomplete requests and uncommon terms. A system may work well with requests from the department involved in building it and struggle with other teams' language.

The test should observe whether the summary preserves important information, whether the suggested routing makes sense and how much work the review requires. It would also be useful to hear from whoever submitted the request: did the new organization make the service clearer? Did any relevant information disappear from the summary?

This evaluation can change the project. Perhaps the team discovers that it needs to improve the intake form before automating triage. Perhaps routing suggestions are useful, but classifying urgency still requires more careful analysis.

Agree on what permits moving forward

I like the idea of separating decisions about experimenting, testing with users and expanding use. Each transition needs a justification appropriate to the impact the solution will have.

During experimentation, the team can investigate whether the approach works with examples prepared for the test. In the pilot, it begins observing use in a defined routine, with people responsible for monitoring. To expand, it needs to assess what it has learned, which failures remain and what capacity it will have to serve more users.

I suggest recording four points at each decision: observed evidence, known limitations, the owner and a review date. The record allows another person to understand why the project advanced and what still needs monitoring.

The right to stop should also be agreed upon. If review takes more time than the original task or relevant information is frequently omitted, the team needs to be able to adjust the scope before expanding use.

Pace is also a management decision

In the article about internal tools with AI, I described how a small NewHack problem became an application. Here, the reflection concerns how to guide that movement when it becomes part of a company's work.

The ease of building creates room for more people to propose solutions. I want to see that space accompanied by better conversations about what is worth doing, how to evaluate it and who needs to participate. A good specification lets the team uncover disagreements while changing direction is still simple.

For founders and leaders, I see an opportunity to turn responsibility into management practice: frame requests better, listen to the people affected and support decisions with evidence. It is a discussion I want to strengthen through NewHack's corporate innovation initiatives, bringing the desire to experiment closer to the conditions needed for a project to work day to day.