« Art exists in limitation » G.K Chesterton. Beautiful, or successful, POCs also thrive on constraints. Constraints allow for the hypothesis you're testing to be answered, no more and no less, and over a reasonably short period of time. 

When you're deciding between speed and quality, choose quality. Slowing down product development to fill in information gaps is more efficient than fixing errors later. 

Data use constraint

The data that you are allowed to use is probably restricted and you need to go through a lengthily process to get access to it. This should force you to be clear about the hypothesis you want to test at POC and only request the necessary data. It's a test of knowing "if [hypothesis] then [we should observe this metric]' and the data you need to measure the metric. 

Ideally, you will not have asked for too little to test your hypothesis as asking for approvals again will reduce your speed, but it can be worked out during POC. 

Scope constraint

There needs to be a clear scope constraint to avoid scope creep, where new hypotheses to test are added to the original POC definition. Defining and staying within the scope constraint will allow you to focus on answering the question you defined. 

If you need to adjust your scope it means the problem was not thoroughly defined at the start. This may be because of a lack of technical information shared in the working group, lack of understanding of the goal of the product, lack of clear definition and separation between POC, MVP and Pilot objectives. 

Performance constraint

In the case of internal AI/ML products, it may be that your product will integrate with an existing solution and provide users with information, such as a prediction. Therefore, you may have a business performance objective e.g. "increase customer retention by 30%", which is the 'north star' and important to know to understand the final value and purpose of the product. However, the success of your AI/ML product should not be measured by north star objectives as they may be dependant on another person or system to act on the information. e.g. you give the information to sales but if they don’t act on it, you may not reach the north star objective, yet it’s not indicative of your model performance. 

Your product's measurable objective or performance should be defined and agreed upon separately. This could be "accurately predicted whether a customer would buy or not buy again". The 'accurately' part will be determined by the Confusion Matrix metrics that were defined e.g. rate of false positives and false negatives that were agreed upon to be acceptable.