Has the ID column configured as PK, NN and AI, be the first column on my table definition?
No.  The order of columns in a table definition does not matter, with one old exception.  In older versions the "first" TIMESTAMP column had a special default DEFAULT value.

It is not required to have an AUTO_INCREMENT.  However it is (essentially) required that you have a PRIMARY KEY.  It smells like AgreementNumber would be such?  Keep in mind that a PK must be UNIQUE (a MySQL requirement).

As a side note, an A_I does not have to be the PK.  The only requirement is that it be the first column in some index.  And remember that a PK is a unique key is a key.

But, that is not your 'real' problem.  That is, you need to do LOAD DATA without the id being provided.

Plan A:  Load into another table, then copy it over.  When copying the data over, specify all the columns except the id; A_I will take care of the rest.

Plan B:  Use LOAD DATA, but specify all the columns except id.  Again A_I will take care of defaulting it correctly.

Other tips, while I have you on the line:


int(1) is a 4-byte number; the (1) means nothing.  Perhaps you want a 1-byte TINYINT?
Use INT UNSIGNED where appropriate
Use datatypes smaller than INT where appropriate; look up MEDIUMINT, and again make it MEDIUMINT UNSIGNED if appropriate.
Use NOT NULL when appropriate.
Don't index flags; they won't be used.
Learn about "composite" indexes. 


More

If you choose to have a 6-column UNIQUE key that includes some VARCHARs, having an A_I is probably better than making that the PK.

A UNIQUE KEY is two things:  An index, and a uniqueness constraint.  You can use it for either or both.

A PK is a UNIQUE KEY that identifies the row.  It also is "clustered" with the data, making lookups more efficient than with a "secondary key" (any non-PK).

When the 'cardinality' of an indexed column is very low, such as for a flag, the Optimizer will dynamically look at the value you provide and see if less than 20% of the table has that value.  In this case, it will use the index; else it will not.  The "20%" varies with the phase of the moon.  The reason for eschewing the index is that using the index involves bouncing back and forth between the index's BTree and the data's BTree via the PK.  This can be slower than simply scanning the data, tossing 80% of the rows.  A secondary key is a BTree containing the indexed column(s) plus a copy of the PK.