After many attempts and a quick search, I found out the exact problem. It was the recovery code. I did the animation with a simple code:
Initial_Frame=1
Final_Frame=360

PovRay exports each frame with a file name and a number. Example brickbank00001.png;brickbank00002.png;brickbank00003.png(...)

If the program crashes, there is a script that reads the last file written and takes the number from that name. It stores the number as a variable "LastFrame" and starts the process from that frame

Initial_Frame=LastFrame
Final_Frame=360

Well, it turns out that this is NOT the way to restart the rendering process. What PovRay does is to divide 1 by 360 and then you have 360 different values in the internal variable called "clock" which is the variable that I used to move the camera position 1 degree at a time. So:

Initial_Frame=1
Final_Frame=360

is not the same as:

Initial_Frame= LastFrame
Final_Frame=360

In the first code you have a "clock" variable that increases 1/360 at a time. In the "recovery code" the "clock" variable increases LastFrame/360. In my case the program crashed around frame 172, so in the new process each frame changed 172/360 at a time.
That's the reason why the first subset of renders looks different to the second subset: The camera rotates at different speeds.

It turns out that the solution is very easy. A simple google search point to the solution:
If you wish to render a subset of frames such as 172 through 360 out of a 1 to 360 animation, you should not change Initial_Frame or Final_Frame. Instead you should use the subset commands.
Subset_Start_Frame=172
Subset_End_Frame=360

It took me almost a week to figure this out, not because of the complexity of the problem, but because each animation took 110 hours to render.@mocbuild101 I managed to remove 300 pieces and saved a couple of hours. It's not easy to identify internal bricks that are not seen in a 360-degree animation when the model has so many windows.