Most teams have already done the experiment. Someone pasted a document into a model, got a good answer, and everyone agreed it was promising. Implementation is everything that happens after that sentence, and it is where most of the effort goes.
In practice it means deciding which decisions stay human and enforcing that in the system rather than in the instructions. It means choosing which model does which kind of work, a local model for volume and privacy, a frontier model for judgement, and making the routing a rule rather than a habit. It means giving each recurring task a schedule, a written procedure, and a receipt that proves it ran, so a person reads outcomes rather than transcripts. It means designing the review path first: the gates, the diffs, the override, the reason field on every human-only action. And it means watching the first run of everything before it is trusted to run alone, then turning each thing that goes wrong into a check that makes it structurally impossible next time.
None of that is a model choice. The models change every few months. What lasts is the shape of the process around them: who may do what, how you know it happened, and what refuses to run when the answer is wrong. That shape is what I build, and the case studies on this site are five versions of it, in production.
My own answers, from my own work. They change when the work does.